+Una volta che un file è stato aperto su può scrivere su di esso utilizzando la
+funzione \func{write}, il cui prototipo è:
+\begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
+
+ Scrive \var{count} byte dal buffer \var{buf} sul file \var{fd}.
+
+ \bodydesc{La funzione ritorna il numero di byte scritti in caso di successo
+ e -1 in caso di errore, nel qual caso \var{errno} viene settata ad uno dei
+ valori:
+ \begin{errlist}
+ \item[\macro{EINVAL}] \var{fd} è connesso ad un oggetto che non consente la
+ scrittura.
+ \item[\macro{EFBIG}] si è cercato di scrivere oltre la dimensione massima
+ consentita dal filesystem o il limite per le dimensioni dei file del
+ processo o su una posizione oltre il massimo consentito.
+ \item[\macro{EPIPE}] \var{fd} è connesso ad una pipe il cui altro capo è
+ chiuso in lettura; in questo caso viene anche generato il segnale
+ \macro{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
+ funzione ritorna questo errore.
+ \item[\macro{EINTR}] la funzione è stata interrotta da un segnale prima di
+ aver potuto scrivere qualsiasi dato.
+ \item[\macro{EAGAIN}] la funzione non aveva nessun dato da restituire e si
+ era aperto il file in modalità \macro{O\_NONBLOCK}.
+ \end{errlist}
+ ed inoltre \macro{EBADF}, \macro{EIO}, \macro{EISDIR}, \macro{EBADF},
+ \macro{ENOSPC}, \macro{EINVAL} e \macro{EFAULT} ed eventuali altri errori
+ dipendenti dalla natura dell'oggetto connesso a \var{fd}.}
+\end{prototype}
+
+Come nel caso di \func{read} la funzione tenta di scrivere \var{count} byte a
+partire dalla posizione corrente nel file e sposta automaticamente la
+posizione in avanti del numero di byte scritti. Se il file è aperto in
+modalità \macro{O\_APPEND} i dati vengono sempre scritti alla fine del file.
+Lo standard POSIX richiede che i dati scritti siano immediatamente disponibili
+ad una \func{read} chiamata dopo che la \func{write} che li ha scritti è
+ritornata; ma dati i meccanismi di caching non è detto che tutti i filesystem
+supportino questa capacità.
+
+Se \var{count} è zero la funzione restituisce zero senza fare nient'altro. Per
+i file ordinari il numero di byte scritti è sempre uguale a quello indicato
+da \var{count}, a meno di un errore. Negli altri casi si ha lo stesso
+comportamento di \func{read}.
+
+Anche per \func{write} lo standard Unix98 definisce una analoga \func{pwrite}
+per scrivere alla posizione indicata senza modificare la posizione corrente
+nel file, il suo prototipo è:
+\begin{prototype}{unistd.h}
+{ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)}
+
+Cerca di scrivere sul file \var{fd}, a partire dalla posizione \var{offset},
+\var{count} byte dal buffer \var{buf}.
+
+\bodydesc{La funzione ritorna il numero di byte letti in caso di successo e -1
+ in caso di errore, nel qual caso \var{errno} viene settata secondo i valori
+ già visti per \func{write} e \func{lseek}.}
+\end{prototype}
+e per essa valgono le stesse considerazioni fatte per \func{pread}.
+
+
+\section{Caratteristiche avanzate}
+\label{sec:file_adv_func}
+
+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 alcune funzioni che
+permettono di eseguire operazioni avanzate con i file.
+
+
+\subsection{La condivisione dei files}
+\label{sec:file_sharing}
+
+In \secref{sec:file_fd} abbiamo descritto brevemente l'architettura
+dell'interfaccia coi 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=13cm]{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 che 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 \var{file\_struct}. Entrambe le voci nella
+\textit{file table} faranno però riferimento allo stesso 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.
+\item se un file è in modalità \macro{O\_APPEND} tutte le volte che viene
+ effettuata una scrittura la posizione corrente viene prima settata alla
+ dimensione corrente del file letta dall'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 \var{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 settata leggendo la dimensione corrente dall'inode.
+\end{itemize}
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=13cm]{img/fileshar}
+ \caption{Schema dell'accesso ai file da parte di un processo figlio}
+ \label{fig:file_acc_child}
+\end{figure}
+
+È comunque possibile che 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 \var{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 è la stesso per entrambi).
+
+Si noti inoltre che anche i flag di stato del file (quelli settati dal
+parametro \var{flag} di \func{open}) essendo tenuti nella voce della
+\textit{file table} (il campo \var{f\_flag} di \var{file}), vengono in questo
+caso condivisi. Ai file però sono associati anche altri flag (l'unico usato al
+momento è \macro{FD\_CLOEXEC}), detti \textit{file descriptor flags}, tenuti
+invece in \var{file\_struct}; questi sono specifici di ciascun processo, e non
+vengono toccati anche in caso di condivisione della voce della \textit{file
+ table}.
+
+
+