titolarità del file viste in \secref{sec:file_ownership}. Il parametro
\var{mode} deve essere specificato. \\
\macro{O\_EXCL} & usato in congiunzione con \macro{O\_CREAT} fa sì che
- l'esistenza del file diventi un errore\protect\footnote{la man page di
- \func{open} segnala che questa opzione è difettosa su NFS, e che i
- programmi che la usano per stabilire un file di lock possono incorrere
- in una race condition. Si consiglia come alternativa di usare un file
- con un nome univoco e la funzione \func{link} per verificarne
- l'esistenza.} che fa fallire \func{open} con \macro{EEXIST}. \\
+ l'esistenza del file diventi un errore\protect\footnotemark\ che fa fallire
+ \func{open} con \macro{EEXIST}. \\
\macro{O\_NONBLOCK} & apre il file in modalità non bloccante. Questo
valore specifica anche una modalità di operazione (vedi sotto), e
comporta che \func{open} ritorni immediatamente (torneremo su
opzione è ignorata. \\
\macro{O\_DIRECTORY} & se \var{pathname} non è una directory la chiamata
fallisce. Questo flag è specifico di Linux ed è stato introdotto con il
- kernel 2.1.126 per evitare dei DoS\protect\footnote{Denial of Service, si
- chiamano così attacchi miranti ad impedire un servizio causando una
- qualche forma di carico eccessivo per il sistema, che resta bloccato
- nelle risposte all'attacco} quando \func{opendir} viene chiamata su una
+ kernel 2.1.126 per evitare dei DoS\protect\footnotemark\ quando
+ \func{opendir} viene chiamata su una
fifo o su un device di unità a nastri, non deve essere utilizzato al di
fuori dell'implementazione di \func{opendir}. \\
\macro{O\_LARGEFILE} & nel caso di sistemi a 32 bit che supportano file di
\macro{O\_APPEND} & il file viene aperto in append mode. Prima di ciascuna
scrittura la posizione corrente viene sempre settata alla fine del
file. Può causare corruzione del file con NFS se più di un processo scrive
- allo stesso tempo\footnote{il problema è che NFS non supporta la scrittura
- in append, ed il kernel deve simularla, ma questo comporta la possibilità
- di una race condition}.\\
+ allo stesso tempo\footnotemark.\\
\macro{O\_NONBLOCK} & il file viene aperto in modalità non bloccante per
le operazioni di I/O: questo significa il fallimento di una \func{read} in
assenza di dati da leggere e quello di una \func{write} in caso di
impossibilità di scrivere immediatamente. L'opzione è effettiva solo per
le fifo e per alcuni file di dispositivo. \\
- \macro{O\_NDELAY} & in Linux\footnote{l'opzione origina da SVr4, dove però
- causava il ritorno da una \func{read} con un valore nullo e non con un
- errore, questo introduce una ambiguità, dato che come vedremo in
- \secref{sec:file_read} il ritorno di zero da parte di \func{read} ha il
- significato di una end-of-file} è sinonimo di \macro{O\_NONBLOCK}.\\
+ \macro{O\_NDELAY} & in Linux\footnotemark\ è sinonimo di
+ \macro{O\_NONBLOCK}.\\
\macro{O\_ASYNC} & apre il file per l'input/output in modalità
asincrona. Non è supportato in Linux. \\
\macro{O\_SYNC} & apre il file per l'input/output sincrono, ogni
\label{tab:file_open_flags}
\end{table}
+\footnotetext[2]{la man page di \func{open} segnala che questa opzione è
+ difettosa su NFS, e che i programmi che la usano per stabilire un file di
+ lock possono incorrere in una race condition. Si consiglia come alternativa
+ di usare un file con un nome univoco e la funzione \func{link} per
+ verificarne l'esistenza.}
+
+\footnotetext[3]{Denial of Service, si chiamano così attacchi miranti ad
+ impedire un servizio causando una qualche forma di carico eccessivo per il
+ sistema, che resta bloccato nelle risposte all'attacco.}
+
+\footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
+ il kernel deve simularla, ma questo comporta la possibilità di una race
+ condition, vedi \secref{sec:file_atomic}.}
+
+\footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
+ una \func{read} con un valore nullo e non con un errore, questo introduce
+ una ambiguità, dato che come vedremo in \secref{sec:file_read} il ritorno di
+ zero da parte di \func{read} ha il significato di una end-of-file.}
+
+
Il nuovo file descriptor non è condiviso con nessun altro processo, (torneremo
sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
\secref{sec:file_sharing}). Il nuovo file descriptor è settato di default per
Crea un nuovo file vuoto, con i permessi specificati da \var{mode}. É del
tutto equivalente a \func{open(filedes, O\_CREAT|O\_WRONLY|O\_TRUNC, mode)}.
\end{prototype}
-
-adesso questa funzione resta solo per compatibilità con i vecchi programmi.
+\noindent adesso questa funzione resta solo per compatibilità con i vecchi
+programmi.
\subsection{La funzione \func{close}}
\item \macro{EBADF} \var{fd} non è un descrittore valido.
\item \macro{EINTR} la funzione è stata interrotta da un segnale.
\end{errlist}
- ed \macro{EIO}.
+ ed inoltre \macro{EIO}.
\end{prototype}
La chiusura di un file rilascia ogni blocco (il \textit{file locking} è
\item \macro{ESPIPE} \var{fd} è una pipe, un socket o una fifo.
\item \macro{EINVAL} \var{whence} non è un valore valido.
\end{errlist}
- e \macro{EBADF}.
+ ed inoltre \macro{EBADF}.
\end{functions}
La nuova posizione è settata usando il valore specificato da \var{offset},
successiva scrittura avvenga alla fine del file, infatti se questo è stato
aperto anche da un altro processo che vi ha scritto, la fine del file può
essersi spostata, ma noi scriveremo alla posizione settata in precedenza.
-Questa è una potenziale sorgente di \textit{race condition}, e quando si vuole
-essere sicuri di scrivere alla fine del file questo deve essere posto in
-modalità \macro{O\_APPEND}.
+(questa è una potenziale sorgente di \textit{race condition}, vedi
+\secref{sec:file_atomic}).
Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
questo caso la funzione ritorna l'errore \macro{EPIPE}. Questo, oltre che per
Come si è visto in un sistema unix è sempre possibile per più processi
accedere in contemporanea allo stesso file, e che le operazioni di lettura e
-scrittura saranno fatte in base alla posizione corrente nel file. Ovviamente
-senza prevedere opportuni meccanismi di sincronizzazione le operazioni
-potranno mescolarsi in maniera imprevedibile. L'unica garanzia è che se si è
-in modalità \macro{O\_APPEND} il sistema assicura che si scriva (con il
-procedimento appena esposto) sempre alla fine del file.
+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}, che esamineremo in \secref{cha:file_advanced}).
+
+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} settare la posizione alla fine
+del file e poi scrivere può condurre ad una \textit{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 settata 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 è una operazione
+atomica; il problema è stato risolto introducendo la modalità
+\macro{O\_APPEND}, in questo caso infatti, come abbiamo visto, è 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 una operazione atomica.
+
+Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
+creare un 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 da parte di un altro processo che crea lo
+stesso file fra il controllo e la creazione.
+
+Per questo motivo sono stati introdotti i flag \macro{O\_CREAT}
+\macro{O\_EXCL}
projects / gapil.git / blobdiff