+stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
+
+Una directory, come vedremo in maggior dettaglio in
+\secref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
+particolare che il kernel riconosce come tale. Il suo scopo è quello di
+contenere una lista di nomi di file e le informazioni che associano ciascun
+nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
+oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
+un'organizzazione ad albero inserendo directory in altre directory.
+
+Un file può essere indicato rispetto alla directory corrente semplicemente
+specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
+ contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
+ components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
+contenuto. All'interno dello stesso albero si potranno poi inserire anche
+tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file
+come le fifo, i link, i socket e gli stessi i file di dispositivo (questi
+ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
+
+Il nome completo di un file viene chiamato \textit{pathname} ed il
+procedimento con cui si individua il file a cui esso fa riferimento è chiamato
+risoluzione del nome (\textit{file name resolution} o \textit{pathname
+ resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da
+sinistra a destra e localizzando ogni nome nella directory indicata dal nome
+precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
+ costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente
+perché il procedimento funzioni occorre che i nomi indicati come directory
+esistano e siano effettivamente directory, inoltre i permessi (si veda
+\secref{sec:file_access_control}) devono consentire l'accesso.
+
+Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
+radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in
+\secref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
+directory radice dell'albero dei file: in questo caso si parla di un
+\textsl{pathname assoluto}\index{pathname assoluto}. Altrimenti la ricerca
+parte dalla directory corrente (su cui torneremo in
+\secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
+ relativo}\index{pathname relativo}.
+
+I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
+in ogni directory, 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; nel caso
+questa sia la directory radice allora il riferimento è a se stessa.
+
+
+\subsection{I tipi di file}
+\label{sec:file_file_types}
+
+Come detto in precedenza in Unix esistono vari tipi di file, in Linux questi
+sono implementati come oggetti del \textit{Virtual File System} (vedi
+\secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
+utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
+\textit{Virtual File System}\index{Virtual File System} è riportato in \ntab.
+
+Si tenga ben presente che questa classificazione non ha nulla a che fare con
+la classificazione sui tipi di file (che in questo caso sono sempre file di
+dati) in base al loro contenuto, o tipo di accesso.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|l|p{7cm}|}
+ \hline
+ \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \textit{regular file} & \textsl{file normale} &
+ 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{inodes}
+ (vedi \secref{sec:file_vfs}). \\
+ \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 che identifica una periferica ad accesso sequenziale \\
+ \textit{block device} & \textsl{dispositivo a blocchi} &
+ un file che identifica una periferica ad accesso diretto \\
+ \textit{fifo} & \textsl{``tubo''} &
+ un file speciale che identifica una linea di comunicazione software
+ (unidirezionale) \\
+ \textit{socket} & \textsl{``spina''} &
+ un file speciale che identifica una linea di comunicazione software
+ (bidirezionale) \\
+ \hline
+ \end{tabular}
+ \caption{Tipologia dei file definiti nel VFS}
+ \label{tab:file_file_types}
+\end{table}
+
+Infatti una delle differenze principali con altri sistemi operativi (come il
+VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono
+un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
+dal sistema file di diverso contenuto o formato (come nel caso di quella fra
+file di testo e binari che c'è in Windows) né c'è una strutturazione a record
+per il cosiddetto ``accesso diretto'' come nel caso del VMS\footnote{con i
+ kernel della serie 2.4 è disponibile una forma di accesso diretto ai dischi
+ (il \textit{raw access}) attraverso dei device file appositi, che però non
+ ha nulla a che fare con questo}.
+
+Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
+codificata in maniera diversa da Windows o Mac, in particolare il fine
+riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
+(\verb|\r|) del Mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
+problemi qualora nei programmi si facciano assunzioni sul terminatore della
+riga.
+
+Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
+dati e che non c'è nessun supporto del sistema per le estensioni come parte
+del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
+i nomi dei file, ad esempio il codice C normalmente si mette in file con
+l'estensione \file{.c}, ma questa è, appunto, solo una convenzione.
+
+
+
+\subsection{Le due interfacce ai file}
+\label{sec:file_io_api}
+
+In Linux le modalità di accesso ai file e le relative interfacce di
+programmazione sono due, basate su due diversi meccanismi con cui è possibile
+accedere al loro contenuto.
+
+La prima è l'interfaccia standard di Unix, quella che il manuale delle
+\acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
+ descriptor}). È un'interfaccia specifica dei sistemi unix-like e provvede
+un accesso non bufferizzato; la tratteremo in dettaglio in
+\capref{cha:file_unix_interface}.
+
+L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
+bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
+direttamente le system call del kernel (in realtà il kernel effettua al suo
+interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
+dispositivi); i \textit{file descriptor}\index{file descriptor} sono
+rappresentati da numeri interi (cioè semplici variabili di tipo \type{int}).
+L'interfaccia è definita nell'header \file{unistd.h}.
+
+La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
+\textit{stream}\index{stream}, essa provvede funzioni più evolute e un accesso
+bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
+tratteremo in dettaglio nel \capref{cha:files_std_interface}.
+
+Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
+anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi
+e sono rappresentati da puntatori ad un opportuna struttura definita dalle
+librerie del C, si accede ad essi sempre in maniera indiretta utilizzando il
+tipo \type{FILE *}. L'interfaccia è definita nell'header \type{stdio.h}.
+
+Entrambe le interfacce possono essere usate per l'accesso ai file come agli
+altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio
+a tempo opportuno), ma per poter accedere alle operazioni di controllo su un
+qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix
+coi \textit{file descriptor}. Allo stesso modo devono essere usati i
+\textit{file descriptor} se si vuole ricorrere a modalità speciali di I/O come
+il polling o il non-bloccante (vedi \capref{cha:file_advanced}).
+
+Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
+quella dei \textit{file descriptor}, che permette di poter scegliere tra
+diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream}
+è che l'interfaccia per le operazioni di input/output è enormemente più ricca
+di quella dei \textit{file descriptor}, che provvedono solo funzioni
+elementari per la lettura/scrittura diretta di blocchi di byte. In
+particolare gli \textit{stream} dispongono di tutte le funzioni di
+formattazione per l'input e l'output adatte per manipolare anche i dati in
+forma di linee o singoli caratteri.
+
+In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
+standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
+uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo
+tempo uno \textit{stream} ad un \textit{file descriptor}.
+
+In generale, se non necessitano specificatamente le funzionalità di basso
+livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
+portabilità, essendo questi ultimi definiti nello standard ANSI C;
+l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
+POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
+
+
+% \subsection{Caratteristiche specifiche dei file in Unix}
+% \label{sec:fileint_unix_spec}
+
+% Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
+% specifiche di un sistema unix-like che devono essere tenute in conto
+% nell'accesso ai file. È infatti normale che più processi o programmi possano
+% accedere contemporaneamente allo stesso file e devono poter eseguire le loro
+% operazioni indipendentemente da quello che fanno gli altri processi.
+
+% Per questo motivo le strutture usate per all'accesso ai file sono relative al
+% processo che effettua l'accesso. All'apertura di ogni file infatti viene
+% creata all'interno del processo una apposita struttura in cui sono memorizzati
+% tutti gli attributi del medesimo, che viene utilizzata per tutte le
+% operazioni. Questa è una struttura che resta locale al processo stesso; in
+% questo modo processi diversi possono usare le proprie strutture locali per
+% accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
+% indipendente.
+
+% Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
+% sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
+% file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
+% successiva. Essa è rappresentata da un numero intero che indica il numero di
+% byte dall'inizio del file, che viene (a meno che non si apra il file in
+% append) inizializzato a zero all'apertura del medesimo.
+
+% Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
+% ogni processo avrà la sua posizione corrente nel file, che non sarà
+% influenzata da quello che altri processi possono fare. Anzi, aprire un file
+% significa appunto creare ed inizializzare una tale struttura, per cui se si
+% apre due volte lo stesso file all'interno dello stesso processo, si otterranno
+% due file descriptor o due stream che avranno ancora una posizione corrente nel
+% file assolutamente indipendente.
+
+% Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
+% accesso è un riferimento all'inode del file, pertanto anche se il file viene
+% cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
+% dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
+% chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
+% in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
+% cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
+% file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
+% saranno disponibili per tutto il tempo in cui il processo è attivo.
+
+% Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
+% l'input/output sui file, esaminando in dettaglio come tutto ciò viene
+% realizzato.
+
+
+\section{L'architettura della gestione dei file}
+\label{sec:file_arch_func}
+
+Per capire fino in fondo le proprietà di file e directory in un sistema
+unix-like ed il comportamento delle relative funzioni di manipolazione occorre
+una breve introduzione al funzionamento gestione dei file da parte del kernel
+e sugli oggetti su cui è basato un filesystem di tipo unix. In particolare
+occorre tenere presente dov'è che si situa la divisione fondamentale fra
+kernel space e user space che tracciavamo al \capref{cha:intro_unix}.
+
+In questa sezione esamineremo come viene implementato l'accesso ai file in
+Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
+prima le caratteristiche generali di un filesystem Unix, per poi trattare in
+maniera un po' più dettagliata il filesystem standard di Linux, l'\acr{ext2}.
+
+
+% in particolare si riprenderà, approfondendolo sul piano
+% dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui
+% abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione
+% nel kernel) in \secref{sec:file_vfs}.