+Grazie a questi identificativi il sistema è in grado di tenere traccia
+dell'utente a cui appartiene ciascun processo ed impedire ad altri utenti di
+interferire con quest'ultimo. Inoltre con questo sistema viene anche
+garantita una forma base di sicurezza interna in quanto anche l'accesso ai
+file (vedi sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo
+di identificazione.
+
+Infine in ogni sistema unix-like è presente uno speciale utente privilegiato,
+il cosiddetto \textit{superuser}, il cui username è di norma \textit{root}, ed
+il cui \ids{UID} è zero. Esso identifica l'amministratore del sistema, che
+deve essere in grado di fare qualunque operazione; per l'utente \textit{root}
+infatti i meccanismi di controllo cui si è accennato in precedenza sono
+disattivati.\footnote{i controlli infatti vengono eseguiti da uno pseudo-codice
+ del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
+
+
+\section{L'architettura di file e directory}
+\label{sec:intro_file_dir}
+
+Come accennato in sez.~\ref{sec:intro_base_concept} uno dei concetti
+fondamentali dell'architettura di un sistema Unix è il cosiddetto
+\textit{everything is a file} (\textsl{tutto è un file}), cioè il fatto che
+l'accesso ai vari dispositivi di input/output del computer viene effettuato
+attraverso un'interfaccia astratta che tratta le periferiche allo stesso modo
+dei normali file di dati.
+
+In questa sezione forniremo una descrizione a grandi linee dell'architettura
+della gestione dei file in Linux, partendo da una introduzione ai concetti di
+base, per poi illustrare la struttura dell'albero dei file ed il significato
+dei tipi di file, concludendo con una panoramica sulle caratteristiche
+principali delle due interfacce con cui i processi possono effettuare l'I/O su
+file.
+
+
+\subsection{Una panoramica generale}
+\label{sec:file_arch_overview}
+
+Per poter accedere ai file, il kernel deve mettere a disposizione dei
+programmi delle opportune \textit{system call} che consentano di leggere e
+scrivere il contenuto. Tutto ciò ha due aspetti: il primo è che il kernel, per
+il concetto dell'\textit{everything is a file}, deve fornire una interfaccia
+che consenta di operare sui file, sia che questi corrispondano ai normali file
+di dati, o ai cosiddetti ``\textsl{file speciali}'', come i file di
+dispositivo (o \textit{device file}) che permettono di accedere alle
+periferiche o le \textit{fifo} ed i socket che forniscono funzionalità di
+comunicazione fra processi (torneremo su questo in sez.~\ref{sec:file_mknod}).
+
+Il secondo aspetto è che per poter utilizzare dei normali file di dati il
+kernel deve provvedere ad organizzare e rendere accessibile in maniera
+opportuna l'informazione in essi contenuta memorizzandola sullo spazio grezzo
+disponibile sui dischi. Questo viene fatto strutturando l'informazione sul
+disco attraverso quello che si chiama un
+``\textit{filesystem}''. L'informazione così strutturata poi viene resa
+disponibile ai processi attraverso quello che viene chiamato il
+``\textsl{montaggio}'' del filesystem nell'albero dei file, dove il contenuto
+sarà accessibile nella forma ordinaria di file e directory.
+
+\itindbeg{Virtual~File~System~(VFS)}
+
+In Linux il concetto di \textit{everything is a file} è stato implementato
+attraverso il cosiddetto \textit{Virtual File System} (da qui in avanti VFS)
+che è uno strato intermedio che il kernel usa per accedere ai più svariati
+filesystem mantenendo la stessa interfaccia per i programmi in \textit{user
+ space}. Il VFS fornisce quel livello di astrazione che permette di
+collegare le operazioni interne del kernel per la manipolazione sui file con
+le \textit{system call} relative alle operazioni di I/O, e gestisce poi
+l'organizzazione di dette operazioni nei vari modi in cui i diversi filesystem
+le effettuano, permettendo la coesistenza di filesystem differenti all'interno
+dello stesso albero delle directory. Approfondiremo il funzionamento di
+interfaccia generica fornita dal VFS in sez.~\ref{sec:file_vfs_work}.
+
+In sostanza quello che accade è che quando un processo esegue una
+\textit{system call} che opera su un file, il kernel chiama sempre una
+funzione implementata nel VFS. La funzione eseguirà le manipolazioni sulle
+strutture generiche e utilizzerà poi delle chiamate alle opportune funzioni
+del filesystem specifico a cui si fa riferimento. Saranno queste infine a
+chiamare le funzioni di più basso livello che eseguono le operazioni di I/O
+sul dispositivo fisico, secondo lo schema riportato in
+fig.~\ref{fig:file_VFS_scheme}.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=8cm]{img/vfs}
+ \caption{Schema delle operazioni del VFS.}
+ \label{fig:file_VFS_scheme}
+\end{figure}
+
+Questa interfaccia resta la stessa anche quando, invece che a dei normali
+file, si accede alle periferiche coi citati file di dispositivo, solo che in
+questo caso invece di usare il codice del filesystem che accede al disco, il
+\textit{Virtual File System} eseguirà direttamente il codice del kernel che
+permette di accedere alla periferica.
+
+\itindend{Virtual~File~System~(VFS)}
+
+Come accennato in precedenza una delle funzioni essenziali per il
+funzionamento dell'interfaccia dei file è quella che consente di montare un
+filesystem nell'albero dei file, e rendere così visibili i suoi contenuti. In
+un sistema unix-like infatti, a differenza di quanto avviene in altri sistemi
+operativi, tutti i file vengono mantenuti all'interno di un unico albero la
+cui radice (quella che viene chiamata \textit{root directory}) viene montata
+all'avvio direttamente dal kernel.
+
+Come accennato in sez.~\ref{sec:intro_kern_and_sys}) montare la radice è,
+insieme al lancio di \cmd{init},\footnote{l'operazione è ovviamente anche
+ preliminare al lancio di \cmd{init}, dato il kernel deve poter accedere al
+ file che contiene detto programma.} l'unica operazione che viene effettuata
+direttamente dal kernel in fase di avvio. Il kernel infatti, completata la
+fase di inizializzazione, utilizza l'indicazione passatagli dal
+\textit{bootloader} su quale sia il dispositivo che contiene il filesystem da
+usare come punto di partenza, lo monta come radice dell'albero dei file.
+
+Tutti gli ulteriori filesystem che possono essere disponibili su altri
+dispositivi dovranno a loro volta essere inseriti nell'albero, montandoli in
+altrettante directory del filesystem radice, su quelli che vengono chiamati
+\textit{mount point}. Questo comunque avverrà sempre in un secondo tempo, a
+cura dei programmi eseguiti nella procedura di inizializzazione del sistema,
+grazie alle funzioni che tratteremo in sez.~\ref{sec:filesystem_mounting}.
+
+
+\subsection{La risoluzione del nome di file e directory}
+\label{sec:file_pathname}
+
+\itindbeg{pathname}
+
+Come appena illustrato sez.~\ref{sec:file_arch_overview} una delle
+caratteristiche distintive di un sistema unix-like è quella di avere un unico
+albero dei file. Un file deve essere identificato dall'utente usando quello
+che viene chiamato il suo \textit{pathname},\footnote{il manuale della
+ \acr{glibc} depreca questa nomenclatura, che genererebbe confusione poiché
+ \textit{path} indica anche un insieme di directory su cui effettuare una
+ ricerca (come quello in cui la shell cerca i comandi). Al suo posto viene
+ proposto l'uso di \textit{filename} e di componente per il nome del file
+ all'interno della directory. Non seguiremo questa scelta dato che l'uso
+ della parola \textit{pathname} è ormai così comune che mantenerne l'uso è
+ senz'altro più chiaro dell'alternativa proposta.} vale a dire tramite il
+``\textsl{percorso}'' (nome che talvolta viene usato come traduzione di
+\textit{pathname}) che si deve fare per accedere al file a partire da una
+certa ``\textit{directory}''.
+
+Una directory in realtà è anch'essa un file, nel senso che è anch'essa un
+oggetto di un filesystem, solo che è un file particolare che il kernel
+riconosce appositamente come tale per poterlo utilizzare come directory. Il
+suo scopo è quello di contenere una lista di nomi di file e le informazioni
+che associano ciascuno di questi nomi al relativo contenuto (torneremo su
+questo in sez.~\ref{sec:file_arch_func}).
+
+Dato che questi nomi possono corrispondere ad un qualunque altro oggetto del
+filesystem, compresa un'altra directory, si ottiene naturalmente
+un'organizzazione ad albero inserendo nomi di directory dentro altre
+directory. All'interno dello stesso albero si potranno poi inserire anche
+tutti gli altri oggetti previsti l'interfaccia del VFS (su cui torneremo in
+sez.~\ref{sec:file_file_types}), come le \textit{fifo}, i collegamenti
+simbolici, i socket e gli stessi file di dispositivo.
+
+La convenzione usata nei sistemi unix-like per indicare i \textit{pathname}
+dei file è quella di usare il carattere ``\texttt{/}'' come separatore fra i
+nomi che indicano le directory che lo compongono. Dato che la directory radice
+sta in cima all'albero, essa viene indicata semplicemente con il
+\textit{pathname} ``\file{/}''.
+
+\itindbeg{pathname~resolution}
+
+Un file può essere indicato rispetto ad una directory semplicemente
+specificandone il nome, il manuale della \acr{glibc} chiama i nomi contenuti
+nelle directory ``componenti'' (in inglese \textit{file name components}), noi
+li chiameremo più semplicemente \textsl{nomi} o \textsl{voci}, riservando la
+parola \textsl{componenti} ai nomi che, separati da una ``\texttt{/}'',
+costituiscono il \textit{pathname}. Questi poi dovranno corrispondere, perché
+il \textit{pathname} sia valido, a voci effettivamente presenti nelle
+directory, ma non è detto che un \textit{pathname} debba per forza risultare
+valido.
+
+Il procedimento con cui dato un \textit{pathname} si individua il file a cui
+esso fa riferimento, è chiamato \textsl{risoluzione del percorso}
+(\textit{filename resolution} o \textit{pathname resolution}). Lo stesso
+procedimento ci può anche dire che il \textit{pathname} usato non è valido.
+La risoluzione viene eseguita esaminando il \textit{pathname} da sinistra a
+destra e localizzando ogni componente dello stesso come nome in una directory
+a partire dalla directory iniziale, usando il carattere ``\texttt{/}'' come
+separatore per scendere dall'una all'altra. Nel caso si indichi un componente
+vuoto il costrutto ``\texttt{//}'' viene considerato equivalente a
+``\texttt{/}''.
+
+Ovviamente perché la risoluzione abbia successo occorre che i componenti
+intermedi esistano e siano effettivamente directory, e che il file o la
+directory indicata dall'ultimo componente esista. Inoltre i permessi relativi
+alle directory indicate nel \textit{pathname} (torneremo su questo
+sez.~\ref{sec:file_access_control}) dovranno consentire l'accesso all'intero
+\textit{pathname}.
+
+\itindsubbeg{pathname}{assoluto}
+\itindsubbeg{pathname}{relativo}
+
+Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
+parte dalla directory radice del processo. Questa, a meno di non avere
+eseguito una \func{chroot} (funzione su cui torneremo in
+sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
+directory radice dell'albero dei file montata dal kernel all'avvio del
+sistema; in questo caso si parla di un \textsl{pathname assoluto}. Altrimenti
+la ricerca parte dalla directory di lavoro corrente del processo (su cui
+torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
+\textsl{pathname relativo}.
+
+\itindsubend{pathname}{assoluto}
+\itindsubend{pathname}{relativo}
+
+Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
+speciale e vengono inseriti in ogni directory quando questa viene creata (vedi
+sez.~\ref{sec:file_dir_creat_rem}). Il primo fa riferimento alla directory
+corrente e il secondo alla directory \textsl{genitrice} (o \textit{parent
+ directory}) cioè la directory che contiene il riferimento alla directory
+corrente.
+
+In questo modo con ``\file{..}'' si può usare un \textit{pathname} relativo
+per indicare un file posto al di sopra della directory corrente, tornando
+all'indietro nell'albero dei file. Questa retromarcia però su fermerà una
+volta raggiunta la directory radice, perché non esistendo in questo caso una
+directory superiore, il nome ``\file{..}'' farà riferimento alla radice
+stessa.
+
+\itindend{pathname}
+\itindend{pathname~resolution}
+
+
+\subsection{I tipi di file}
+\label{sec:file_file_types}
+
+Parlare dei tipi di file su Linux, come per qualunque sistema unix-like,
+significa anzitutto chiarire il proprio vocabolario e sottolineare le
+differenze che ci sono rispetto ad altri sistemi operativi.
+
+\index{file!di~dispositivo|(}
+\index{file!speciali|(}
+
+Come accennato in sez.~\ref{sec:file_arch_overview} su Linux l'uso del
+\textit{Virtual File System} consente di trattare come file oggetti molto
+diversi fra loro. Oltre ai normali file di dati abbiamo già accennato ad altri
+due di questi oggetti, i file di dispositivo e le directory, ma ne esistono
+altri. In genere quando si parla di tipo di file su Linux si fa riferimento a
+questi diversi tipi, di cui si riportato l'elenco completo in
+tab.~\ref{tab:file_file_types}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|l|p{6cm}|}
+ \hline
+ \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \textit{regular file}& \textsl{file regolare}
+ & Un file che contiene dei dati (l'accezione
+ normale di file).\\
+ \textit{directory} &\textsl{cartella o direttorio}
+ & Un file che contiene una lista di nomi associati
+ a degli \textit{inode} (vedi
+ sez.~\ref{sec:file_vfs_work}).\\
+ \textit{symbolic link}&\textsl{collegamento simbolico}
+ & Un file che contiene un riferimento ad un altro
+ file/directory.\\
+ \textit{char device} &\textsl{dispositivo a caratteri}
+ & Un file \textsl{speciale} che identifica una
+ periferica ad accesso a caratteri.\\
+ \textit{block device}& \textsl{dispositivo a blocchi}
+ & Un file \textsl{speciale} che identifica una
+ periferica ad accesso a blocchi.\\
+ \textit{fifo} & ``\textsl{coda}''
+ & Un file \textsl{speciale} che identifica una
+ linea di comunicazione unidirezionale (vedi
+ sez.~\ref{sec:ipc_named_pipe}).\\
+ \textit{socket} & ``\textsl{presa}''
+ & Un file \textsl{speciale} che identifica una
+ linea di comunicazione bidirezionale (vedi
+ cap.~\ref{cha:socket_intro}).\\
+ \hline
+ \end{tabular}
+ \caption{Tipologia dei file definiti nel VFS}
+ \label{tab:file_file_types}
+\end{table}