+In questa sezione approfondiremo alcune delle caratteristiche più sottili
+della gestione file in un sistema unix-like, esaminando in dettaglio il
+comportamento delle funzioni base, inoltre tratteremo le funzioni che
+permettono di eseguire alcune operazioni avanzate con i file (il grosso
+dell'argomento sarà comunque affrontato in \capref{cha:file_advanced}).
+
+
+\subsection{La condivisione dei files}
+\label{sec:file_sharing}
+
+In \secref{sec:file_fd} abbiamo descritto brevemente l'architettura
+dell'interfaccia con i file da parte di un processo, mostrando in
+\figref{fig:file_proc_file} le principali strutture usate dal kernel;
+esamineremo ora in dettaglio le conseguenze che questa architettura ha nei
+confronti dell'accesso allo stesso file da parte di processi diversi.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=15cm]{img/filemultacc}
+ \caption{Schema dell'accesso allo stesso file da parte di due processi
+ diversi}
+ \label{fig:file_mult_acc}
+\end{figure}
+
+Il primo caso è quello in cui due processi diversi aprono lo stesso file
+su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una
+situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun
+processo avrà una sua voce nella \textit{file table} referenziata da un
+diverso file descriptor nella sua \struct{file\_struct}. Entrambe le voci
+nella \textit{file table} faranno però riferimento allo stesso
+inode\index{inode} su disco.
+
+Questo significa che ciascun processo avrà la sua posizione corrente sul file,
+la sua modalità di accesso e versioni proprie di tutte le proprietà che
+vengono mantenute nella sua voce della \textit{file table}. Questo ha
+conseguenze specifiche sugli effetti della possibile azione simultanea sullo
+stesso file, in particolare occorre tenere presente che:
+\begin{itemize}
+\item ciascun processo può scrivere indipendentemente; dopo ciascuna
+ \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
+ scrittura eccede la dimensione corrente del file questo verrà esteso
+ automaticamente con l'aggiornamento del campo \var{i\_size}
+ nell'inode\index{inode}.
+\item se un file è in modalità \const{O\_APPEND} tutte le volte che viene
+ effettuata una scrittura la posizione corrente viene prima impostata alla
+ dimensione corrente del file letta dall'inode\index{inode}. Dopo la
+ scrittura il file viene automaticamente esteso.
+\item l'effetto di \func{lseek} è solo quello di cambiare il campo
+ \var{f\_pos} nella struttura \struct{file} della \textit{file table}, non
+ c'è nessuna operazione sul file su disco. Quando la si usa per porsi alla
+ fine del file la posizione viene impostata leggendo la dimensione corrente
+ dall'inode\index{inode}.
+\end{itemize}
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=15cm]{img/fileshar}
+ \caption{Schema dell'accesso ai file da parte di un processo figlio}
+ \label{fig:file_acc_child}
+\end{figure}
+
+Il secondo caso è quello in cui due file descriptor di due processi diversi
+puntino alla stessa voce nella \textit{file table}; questo è ad esempio il
+caso dei file aperti che vengono ereditati dal processo figlio all'esecuzione
+di una \func{fork} (si ricordi quanto detto in \secref{sec:proc_fork}). La
+situazione è illustrata in \figref{fig:file_acc_child}; dato che il processo
+figlio riceve una copia dello spazio di indirizzi del padre, riceverà anche
+una copia di \struct{file\_struct} e relativa tabella dei file aperti.
+
+In questo modo padre e figlio avranno gli stessi file descriptor che faranno
+riferimento alla stessa voce nella \textit{file table}, condividendo così la
+posizione corrente sul file. Questo ha le conseguenze descritte a suo tempo in
+\secref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
+corrente nel file varierà per entrambi i processi (in quanto verrà modificato
+\var{f\_pos} che è lo stesso per entrambi).
+
+Si noti inoltre che anche i flag di stato del file (quelli impostati
+dall'argomento \param{flag} di \func{open}) essendo tenuti nella voce della
+\textit{file table}\footnote{per la precisione nel campo \var{f\_flags} di
+ \struct{file}.}, vengono in questo caso condivisi. Ai file però sono
+associati anche altri flag, dei quali l'unico usato al momento è
+\const{FD\_CLOEXEC}, detti \textit{file descriptor flags}. Questi ultimi sono
+tenuti invece in \struct{file\_struct}, e perciò sono specifici di ciascun
+processo e non vengono modificati dalle azioni degli altri anche in caso di
+condivisione della stessa voce della \textit{file table}.
+
+
+
+\subsection{Operazioni atomiche con i file}
+\label{sec:file_atomic}
+
+Come si è visto in un sistema unix-like è sempre possibile per più processi
+accedere in contemporanea allo stesso file, e che le operazioni di lettura e
+scrittura possono essere fatte da ogni processo in maniera autonoma in base
+ad una posizione corrente nel file che è locale a ciascuno di essi.
+
+Se dal punto di vista della lettura dei dati questo non comporta nessun
+problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
+maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
+di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
+utilizzare meccanismi di sincronizzazione più complessi (come il \textit{file
+ locking}\index{file!locking}, che esamineremo in \secref{sec:file_locking}).
+
+Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
+vari processi devono scrivere alla fine di un file (ad esempio un file di
+log). Come accennato in \secref{sec:file_lseek} impostare la posizione alla
+fine del file e poi scrivere può condurre ad una \textit{race
+ condition}\index{race condition}: infatti può succedere che un secondo
+processo scriva alla fine del file fra la \func{lseek} e la \func{write}; in
+questo caso, come abbiamo appena visto, il file sarà esteso, ma il nostro
+primo processo avrà ancora la posizione corrente impostata con la \func{lseek}
+che non corrisponde più alla fine del file, e la successiva \func{write}
+sovrascriverà i dati del secondo processo.
+
+Il problema è che usare due system call in successione non è un'operazione
+atomica; il problema è stato risolto introducendo la modalità
+\const{O\_APPEND}. In questo caso infatti, come abbiamo descritto in
+precedenza, è il kernel che aggiorna automaticamente la posizione alla fine
+del file prima di effettuare la scrittura, e poi estende il file. Tutto questo
+avviene all'interno di una singola system call (la \func{write}) che non
+essendo interrompibile da un altro processo costituisce un'operazione atomica.
+
+Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
+creare un \textsl{file di lock}\index{file!di lock}, bloccandosi se il file
+esiste. In questo caso la sequenza logica porterebbe a verificare prima
+l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
+di nuovo avremmo la possibilità di una race condition\index{race condition} da
+parte di un altro processo che crea lo stesso file fra il controllo e la
+creazione.
+
+Per questo motivo sono stati introdotti per \func{open} i due flag
+\const{O\_CREAT} e \const{O\_EXCL}. In questo modo l'operazione di controllo
+dell'esistenza del file (con relativa uscita dalla funzione con un errore) e
+creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno
+di una singola system call (per i dettagli sull'uso di questa caratteristica
+si veda \secref{sec:ipc_file_lock}).
+
+
+\subsection{La funzioni \func{sync} e \func{fsync}}
+\label{sec:file_sync}
+
+Come accennato in \secref{sec:file_close} tutte le operazioni di scrittura
+sono in genere bufferizzate dal kernel, che provvede ad effettuarle in maniera
+asincrona (ad esempio accorpando gli accessi alla stessa zona del disco) in un
+secondo tempo rispetto al momento della esecuzione della \func{write}.
+
+Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
+sistema mette a disposizione delle funzioni che provvedono a forzare lo
+scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
+ questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
+ l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
+ ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
+ scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
+prototipo è:
+\begin{prototype}{unistd.h}{int sync(void)}
+
+ Sincronizza il buffer della cache dei file col disco.
+
+ \bodydesc{La funzione ritorna sempre zero.}
+\end{prototype}
+\noindent i vari standard prevedono che la funzione si limiti a far partire
+le operazioni, ritornando immediatamente; in Linux (dal kernel 1.3.20) invece
+la funzione aspetta la conclusione delle operazioni di sincronizzazione del
+kernel.
+
+La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
+esplicitamente lo scarico dei dati su disco, o dal demone di sistema
+\cmd{update} che esegue lo scarico dei dati ad intervalli di tempo fissi: il
+valore tradizionale, usato da BSD, per l'update dei dati è ogni 30 secondi, ma
+in Linux il valore utilizzato è di 5 secondi; con le nuove versioni\footnote{a
+ partire dal kernel 2.2.8} poi, è il kernel che si occupa direttamente di
+tutto quanto attraverso il demone interno \cmd{bdflush}, il cui comportamento
+può essere controllato attraverso il file \file{/proc/sys/vm/bdflush} (per il
+significato dei valori si può leggere la documentazione allegata al kernel in
+\file{Documentation/sysctl/vm.txt}).
+
+Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
+sicuri che i dati di un database sono stati registrati su disco) si possono
+usare le due funzioni \funcd{fsync} e \funcd{fdatasync}, i cui prototipi sono:
+\begin{functions}
+ \headdecl{unistd.h}
+ \funcdecl{int fsync(int fd)}
+ Sincronizza dati e metadati del file \param{fd}
+ \funcdecl{int fdatasync(int fd)}
+ Sincronizza i dati del file \param{fd}.
+
+ \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
+ nel qual caso \var{errno} assume i valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
+ sincronizzazione.
+ \end{errlist}
+ ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO}.}
+\end{functions}
+
+Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
+file specificato, ed attendono fino alla conclusione delle operazioni;
+\func{fsync} forza anche la sincronizzazione dei metadati del file (che
+riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
+altri dati contenuti nell'inode\index{inode} che si leggono con \func{fstat},
+come i tempi del file).
+
+Si tenga presente che questo non comporta la sincronizzazione della
+directory che contiene il file (e scrittura della relativa voce su
+disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
+ il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
+ il kernel provvede anche alla sincronizzazione automatica delle voci
+ delle directory.}
+
+
+\subsection{La funzioni \func{dup} e \func{dup2}}