+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\ \}}''.}
+
+
+%Rimosse
+% \section{L'architettura della gestione dei file}
+% \label{sec:file_arch_func}
+
+\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 \index{file!speciali} ``\textsl{file speciali}'',
+come \index{file!di~dispositivo} i file di dispositivo (o \textit{device
+ file}) che permettono di accedere alle periferiche o le fifo ed i socket che
+forniscono funzionalità di comunicazione fra processi.
+
+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}
+
+In Linux il concetto di \textit{everything is a file} è stato implementato
+attraverso il \textit{Virtual File System} (che da qui in poi abbrevieremo in
+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 cioè 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 la chiamata alle opportune funzioni del
+filesystem specifico a cui si fa riferimento. Saranno queste 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=7cm]{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 \index{file!di~dispositivo} 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}
+
+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 quando, completata la fase di
+inizializzazione, esso riceve dal bootloader l'indicazione di quale
+dispositivo contiene il filesystem da usare come punto di partenza e questo
+viene posto alla 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 su
+altrettante directory del filesystem radice, su quelli che vengono chiamati
+\index{mount~point} \textit{mount point}. Questo comunque avverrà sempre in
+un secondo tempo, in genere 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 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
+\itindex{Virtual~File~System} VFS (su cui torneremo in
+sez.~\ref{sec:file_file_types}), come le fifo, i collegamenti simbolici, i
+socket e gli stessi \index{file!di~dispositivo} 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}.
+
+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}
+\itindsub{pathname}{assoluto}. Altrimenti la ricerca parte dalla
+\index{directory~di~lavoro} directory di lavoro corrente del processo (su cui
+torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
+\itindsub{pathname}{relativo} \textsl{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 \itindsub{pathname}{relativo}
+\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.
+
+Come accennato in sez.~\ref{sec:file_arch_overview} su Linux l'uso del
+\itindex{Virtual~File~System} \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, 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
+ \itindex{inode} \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}