-La terza categoria è quella dei \textsl{i bit delle modalità di apertura}
-che permettono di specificare alcune delle caratteristiche del comportamento
-di \func{open} quando viene eseguita. Hanno effetto solo al momento della
-chiamata della funzione e non sono memorizzati né possono essere riletti.
-
-\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
-
- \item[\const{O\_APPEND}] Il file viene aperto in \itindex{append~mode}
- \textit{append mode}. Prima di ciascuna scrittura la posizione corrente
- viene sempre impostata alla fine del file. Con NFS si può avere una
- corruzione del file se più di un processo scrive allo stesso
- tempo.\footnote{il problema è che NFS non supporta la scrittura in
- \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma
- questo comporta la possibilità di una \itindex{race~condition}
- \textit{race condition}, vedi sez.~\ref{sec:file_atomic}.}
-
- \item[\const{O\_NONBLOCK}] Il file viene aperto in modalità non bloccante
- per le operazioni di I/O (che tratteremo in
- sez.~\ref{sec:file_noblocking}): questo significa il fallimento di
- \func{read} in assenza di dati da leggere e quello di \func{write} in caso
- di impossibilità di scrivere immediatamente. Questa modalità ha senso solo
- per le fifo e per alcuni file di dispositivo.
-
- \item[\const{O\_NONBLOCK}] Apre il file in modalità non bloccante, e
- comporta che \func{open} ritorni immediatamente anche quando dovrebbe
- bloccarsi (l'opzione ha senso solo per le fifo, vedi
- sez.~\ref{sec:ipc_named_pipe}).
-
- \item[\const{O\_NDELAY}] In Linux è sinonimo di
- \const{O\_NONBLOCK}.\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 un'ambiguità, dato che come vedremo in
- sez.~\ref{sec:file_read} il ritorno di zero da parte di \func{read} ha
- il significato di una \textit{end-of-file}.}
-
- \item[\const{O\_ASYNC}] Apre il file per l'I/O in modalità asincrona (vedi
- sez.~\ref{sec:file_asyncronous_io}). Quando è impostato viene generato il
- segnale \signal{SIGIO} tutte le volte che sono disponibili dati in input
- sul file.
-
- \item[\const{O\_SYNC}] Apre il file per l'input/output sincrono: ogni
- \func{write} bloccherà fino al completamento della scrittura di tutti i
- dati sull'hardware sottostante.
-
- \item[\const{O\_FSYNC}] Sinonimo di \const{O\_SYNC}, usato da BSD.
-
- \item[\const{O\_DSYNC}] Variante di I/O sincrono definita da POSIX; presente
- dal kernel 2.1.130 come sinonimo di \const{O\_SYNC}.
-
- \item[\const{O\_RSYNC}] Variante analoga alla precedente, trattata allo
- stesso modo.
-
- \item[\const{O\_NOATIME}] Blocca l'aggiornamento dei tempi di accesso dei
- file (vedi sez.~\ref{sec:file_file_times}). Per molti filesystem questa
- funzionalità non è disponibile per il singolo file ma come opzione
- generale da specificare in fase di montaggio.
-
- \item[\const{O\_DIRECT}] Esegue l'I/O direttamente dai buffer in user space
- in maniera sincrona, in modo da scavalcare i meccanismi di caching del
- kernel. In genere questo peggiora le prestazioni tranne quando le
- applicazioni ottimizzano il proprio caching.\footnote{l'opzione è stata
- introdotta dalla SGI in IRIX, e serve sostanzialmente a permettere ad
- alcuni programmi (in genere database) la gestione diretta della
- bufferizzazione dell'I/O in quanto essi sono in grado di ottimizzarla al
- meglio per le loro prestazioni; l'opzione è presente anche in FreeBSD,
- senza limiti di allineamento dei buffer. In Linux è stata introdotta con
- il kernel 2.4.10, le versioni precedenti la ignorano.} Per i kernel
- della serie 2.4 si deve garantire che i buffer in user space siano
- allineati alle dimensioni dei blocchi del filesystem; per il kernel 2.6
- basta che siano allineati a multipli di 512 byte.
-
- \item[\const{O\_CLOEXEC}] Attiva la modalità di \itindex{close-on-exec}
- \textit{close-on-exec} (vedi sez.~\ref{sec:file_sharing} e
- \ref{sec:file_fcntl}).\footnote{introdotto con il kernel 2.6.23, per
- evitare una \itindex{race~condition} \textit{race condition} che si può
- verificare con i \itindex{thread} \textit{thread}, fra l'apertura del
- file e l'impostazione della suddetta modalità con \func{fcntl}.}
- \end{basedescript}
-
-
-%TODO trattare le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
-% nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
-
-
-In tab.~\ref{tab:file_open_flags} sono riportate, ordinate e divise fra loro
-secondo le tre modalità appena elencate, le costanti mnemoniche associate a
-ciascuno di questi bit. Dette costanti possono essere combinate fra loro con
-un OR aritmetico per costruire il valore (in forma di maschera binaria)
-dell'argomento \param{flags} da passare alla \func{open}. I due flag
-\const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono estensioni specifiche di
-Linux, e deve essere definita la macro \macro{\_GNU\_SOURCE} per poterli
-usare.
+A differenza di tutti gli altri flag che vedremo in seguito, in questo caso
+non si ha a che fare con singoli bit separati dell'argomento \param{flags}, ma
+con un numero composto da due bit. Questo significa ad esempio che la
+combinazione \code{\const{O\_RDONLY}|\const{O\_WRONLY}} non è affatto
+equivalente a \const{O\_RDWR}, e non deve essere usata.\footnote{in realtà
+ su Linux, dove i valori per le tre costanti di
+ tab.~\ref{tab:open_access_mode_flag} sono rispettivamente $0$, $1$ e $2$, il
+ valore $3$ viene usato con un significato speciale, ed assolutamente fuori
+ standard, disponibile solo per i file di dispositivo e solo per alcuni
+ driver, in cui si richiede la verifica della capacità di accesso in lettura
+ e scrittura ma viene restituito un file descriptor che non può essere letto
+ o scritto, ma solo usato con una \func{ioctl} (vedi
+ sez.~\ref{sec:file_fcntl_ioctl}).}
+
+La modalità di accesso deve sempre essere specificata quando si apre un file,
+il valore indicato in \param{flags} viene salvato nei
+\itindex{file~status~flag} \textit{file status flags}, e può essere riletto
+con \func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}), il relativo valore
+può essere poi ottenuto un AND aritmetico della maschera binaria
+\const{O\_ACCMODE}, ma non può essere modificato. Nella \acr{glibc} sono
+definite inoltre \const{O\_READ} come sinonimo di \const{O\_RDONLY} e
+\const{O\_WRITE} come sinonimo di \const{O\_WRONLY}.\footnote{si tratta di
+ definizioni completamente fuori standard, attinenti, insieme a
+ \const{O\_EXEC} che permetterebbe l'apertura di un file per l'esecuzione, ad
+ un non meglio precisato ``\textit{GNU system}''; pur essendo equivalenti
+ alle definizioni classiche non è comunque il caso di utilizzarle.}
+
+Il secondo gruppo di flag è quello delle \textsl{modalità di
+ apertura},\footnote{la pagina di manuale di \func{open} parla di
+ \textit{file creation flags}, ma alcuni di questi flag non hanno nulla a che
+ fare con la creazione dei file, mentre il manuale dalla \acr{glibc} parla di
+ più correttamente di \textit{open-time flags}, dato che si tratta di flag il
+ cui significato ha senso solo al momento dell'apertura del file.} che
+permettono di specificare alcune delle caratteristiche del comportamento di
+\func{open} nel momento in viene eseguita per aprire un file. Questi flag
+hanno effetto solo nella chiamata della funzione, non sono memorizzati fra i
+\itindex{file~status~flag} \textit{file status flags} e non possono essere
+riletti da \func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{10 cm}|}
+ \hline
+ \textbf{Flag} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{O\_CREAT} & Se il file non esiste verrà creato, con le regole
+ di titolarità del file viste in
+ sez.~\ref{sec:file_ownership_management}. Se si
+ imposta questo flag l'argomento \param{mode} deve
+ essere sempre specificato.\\
+ \const{O\_DIRECTORY}& Se \param{pathname} non è una directory la
+ chiamata fallisce. Questo flag, introdotto con il
+ kernel 2.1.126, è specifico di Linux e
+ serve ad evitare dei possibili
+ \itindex{Denial~of~Service~(DoS)}
+ \textit{DoS}\footnotemark quando \func{opendir}
+ viene chiamata su una fifo o su un dispositivo
+ associato ad una unità a nastri. Non viene
+ usato al di fuori dell'implementazione di
+ \func{opendir}, ed è utilizzabile soltanto se si è
+ definita la macro \macro{\_GNU\_SOURCE}.\\
+ \const{O\_EXCL} & Deve essere usato in congiunzione con
+ \const{O\_CREAT} ed in tal caso impone che il file
+ indicato da \param{pathname} non sia già esistente
+ (altrimenti causa il fallimento della chiamata con
+ un errore di \errcode{EEXIST}).\\
+ \const{O\_LARGEFILE}& Viene usato sui sistemi a 32 bit per richiedere
+ l'apertura di file molto grandi, la cui
+ dimensione non è rappresentabile con la versione a
+ 32 bit del tipo \type{off\_t}, utilizzando
+ l'interfaccia alternativa abilitata con la
+ macro \macro{\_LARGEFILE64\_SOURCE}. Come
+ illustrato in sez.~\ref{sec:intro_gcc_glibc_std} è
+ sempre preferibile usare la conversione automatica
+ delle funzioni che si attiva assegnando a $64$ la
+ macro \macro{\_FILE\_OFFSET\_BITS}, e non usare mai
+ questo flag.\\
+ \const{O\_NOCTTY} & Se \param{pathname} si riferisce ad un dispositivo
+ di terminale, questo non diventerà il terminale di
+ controllo, anche se il processo non ne ha ancora
+ uno (si veda sez.~\ref{sec:sess_ctrl_term}).\\
+ \const{O\_NOFOLLOW} & Se \param{pathname} è un collegamento simbolico
+ la chiamata fallisce. Questa è un'estensione BSD
+ aggiunta in Linux a partire dal kernel
+ 2.1.126, ed utilizzabile soltanto se si è definita
+ la macro \macro{\_GNU\_SOURCE}.\\
+ \const{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
+ ne tronca la lunghezza a zero; con un terminale o
+ una fifo viene ignorato, negli altri casi il
+ comportamento non è specificato.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti che identificano le \textit{modalità di apertura} di
+ un file.}
+ \label{tab:open_time_flag}
+\end{table}
+
+\footnotetext{acronimo di \itindex{Denial~of~Service~(DoS)} \textit{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.}
+
+Si è riportato in tab.~\ref{tab:open_time_flag} l'elenco dei flag delle
+\textsl{modalità di apertura}.\footnote{la \acr{glibc} definisce anche i due
+ flag \const{O\_SHLOCK}, che aprirebbe il file con uno \textit{shared lock} e
+ \const{O\_EXLOCK} che lo aprirebbe con un \textit{exclusive lock} (vedi
+ sez.~\ref{sec:file_locking}, si tratta di opzioni specifiche di BSD, che non
+ esistono con Linux.} Uno di questi, \const{O\_EXCL}, ha senso solo se usato
+in combinazione a \const{O\_CREAT} quando si vuole creare un nuovo file per
+assicurarsi che questo non esista di già, e lo si usa spesso per creare i
+cosiddetti \index{file!di lock} ``\textsl{file di lock}'' (vedi
+sez.~\ref{sec:ipc_file_lock}). Si tenga presente che questa opzione è
+supportata su NFS solo a partire da NFSv3 e con il kernel 2.6, nelle versioni
+precedenti la funzionalità viene emulata controllando prima l'esistenza del
+file per cui usarla per creare \index{file!di lock} un file di lock potrebbe
+dar luogo a una \itindex{race~condition} \textit{race condition}.\footnote{un
+ file potrebbe venir creato fra il controllo la successiva apertura con
+ \const{O\_CREAT}, la cosa si può risolvere comunque creando un file con un
+ nome univoco ed usando la funzione \func{link} per creare il \index{file!di
+ lock} file di lock, (vedi sez.~\ref{sec:ipc_file_lock}).}
+
+Se si usa \const{O\_EXCL} senza \const{O\_CREAT} il comportamento è
+indefinito. Nella creazione di un file con \const{O\_CREAT} occorre sempre
+specificare l'argomento di \param{mode}, che altrimenti è ignorato. Si tenga
+presente che indipendentemente dai permessi che si possono assegnare, che in
+seguito potrebbero non consentire lettura o scrittura, quando il file viene
+aperto l'accesso viene garantito secondo quanto richiesto con i flag di
+tab.~\ref{tab:open_access_mode_flag}. Quando viene creato un nuovo file
+\const{O\_CREAT} con tutti e tre i tempi del file di
+tab.~\ref{tab:file_file_times} vengono impostati al tempo corrente. Se invece
+si tronca il file con \const{O\_TRUNC} verranno impostati soltanto il
+\textit{modification time} e lo \textit{status change time}.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{10 cm}|}
+ \hline
+ \textbf{Flag} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{O\_APPEND} & Il file viene aperto in \itindex{append~mode}
+ \textit{append mode}. La posizione sul file (vedi
+ sez.~\ref{sec:file_lseek}) viene sempre mantenuta
+ sulla sua coda, per cui quanto si scrive
+ viene sempre aggiunto al contenuto precedente. Con
+ NFS questa funzionalità non è supportata
+ e viene emulata, per questo possono verificarsi
+ \itindex{race~condition} \textit{race
+ condition} con una sovrapposizione dei dati se
+ più di un processo scrive allo stesso tempo. \\
+ \const{O\_ASYNC} & Apre il file per l'I/O in modalità asincrona (vedi
+ sez.~\ref{sec:signal_driven_io}). Quando è
+ impostato viene generato il segnale \signal{SIGIO}
+ tutte le volte che il file è pronto per le
+ operazioni di lettura o scrittura. Questo flag si
+ può usare solo terminali, pseudo-terminali e socket
+ e, a partire dal kernel 2.6, anche sulle fifo. Per
+ un bug dell'implementazione non è opportuno usarlo
+ in fase di apertura del file, deve
+ invece essere attivato successivamente con
+ \func{fcntl}.\\
+ \const{O\_CLOEXEC}& Attiva la modalità di \itindex{close-on-exec}
+ \textit{close-on-exec} (vedi
+ sez.~\ref{sec:proc_exec}) sul file. Il flag è
+ previsto dallo standard POSIX.1-2008, ed è stato
+ introdotto con il kernel 2.6.23 per evitare una
+ \itindex{race~condition} \textit{race condition}
+ che si potrebbe verificare con i \textit{thread}
+ fra l'apertura del file e l'impostazione della
+ suddetta modalità con \func{fcntl} (vedi
+ sez.~\ref{sec:file_fcntl_ioctl}).\\
+ \const{O\_DIRECT} & Esegue l'I/O direttamente dalla memoria in
+ \textit{user space} in maniera sincrona, in modo da
+ scavalcare i meccanismi di bufferizzazione del
+ kernel. Introdotto con il kernel 2.4.10 ed
+ utilizzabile soltanto se si è definita la
+ macro \macro{\_GNU\_SOURCE}.\\
+ \const{O\_NOATIME} & Blocca l'aggiornamento dei tempi di accesso dei
+ file (vedi sez.~\ref{sec:file_file_times}). Per
+ molti filesystem questa funzionalità non è
+ disponibile per il singolo file ma come opzione
+ generale da specificare in fase di
+ montaggio. Introdotto con il kernel 2.6.8 ed
+ utilizzabile soltanto se si è definita la
+ macro \macro{\_GNU\_SOURCE}.\\
+ \const{O\_NONBLOCK}& Apre il file in \textsl{modalità non bloccante} per
+ le operazioni di I/O (vedi
+ sez.~\ref{sec:file_noblocking}). Questo significa
+ il fallimento delle successive operazioni di
+ lettura o scrittura qualora il file non sia pronto
+ per la loro esecuzione immediata, invece del
+ blocco delle stesse in attesa di una successiva
+ possibilità di esecuzione come avviene
+ normalmente. Questa modalità ha senso solo per le
+ fifo, vedi sez.~\ref{sec:ipc_named_pipe}), o quando
+ si vuole aprire un file di dispositivo per eseguire
+ una \func{ioctl} (vedi
+ sez.~\ref{sec:file_fcntl_ioctl}).\\
+ \const{O\_NDELAY} & In Linux è un sinonimo di \const{O\_NONBLOCK}, ma
+ origina da SVr4, dove però causava il ritorno da
+ una \func{read} con un valore nullo e non con un
+ errore, questo introduce un'ambiguità, dato che
+ come vedremo in sez.~\ref{sec:file_read} il ritorno
+ di un valore nullo da parte di \func{read} ha
+ il significato di una \textit{end-of-file}.\\
+ \const{O\_SYNC} & Apre il file per l'input/output sincrono. Ogni
+ scrittura si bloccherà fino alla conferma
+ dell'arrivo di tutti i dati e di tutti i metadati
+ sull'hardware sottostante (in questo significato
+ solo dal kernel 2.6.33).\\
+ \const{O\_DSYNC} & Apre il file per l'input/output sincrono. Ogni
+ scrittura di dati si bloccherà fino alla conferma
+ dell'arrivo degli stessi e della parte di metadati
+ ad essi relativa sull'hardware sottostante (in
+ questo significato solo dal kernel 2.6.33).\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti che identificano le \textit{modalità di operazione} di
+ un file.}
+ \label{tab:open_operation_flag}
+\end{table}
+
+Il terzo gruppo è quello dei flag delle \textsl{modalità di operazione},
+riportati in tab.~\ref{tab:open_operation_flag}, che permettono di specificare
+varie caratteristiche del comportamento delle operazioni di I/O che verranno
+eseguite sul file. Tutti questi, tranne \const{O\_CLOEXEC}, che viene
+mantenuto per ogni singolo file descriptor, vengono salvati nel campo
+\var{f\_flags} della struttura \kstruct{file} insieme al valore della
+\textsl{modalità di accesso} andando far parte dei cosiddetti \textit{file
+ status flags}. Il loro valore viene impostato alla chiamata di \func{open},
+ma possono venire riletti in un secondo tempo con \func{fcntl}, inoltre alcuni
+di essi possono anche essere modificati tramite questa funzione, con
+conseguente effetto sulle caratteristiche operative che controllano (torneremo
+sull'argomento in sez.~\ref{sec:file_fcntl_ioctl}).
+
+Il flag \const{O\_ASYNC} (che, per per compatibilità con BSD, si può indicare
+anche con la costante \const{FASYNC}) è definito come possibile valore per
+\func{open}, ma per un bug dell'implementazione,\footnote{segnalato come
+ ancora presente nella pagina di manuale almeno fino al Settembre 2011.} non
+solo non attiva il comportamento citato, ma se usato richiede di essere
+esplicitamente disattivato prima di essere attivato in maniera effettiva con
+l'uso di \func{fcntl}. Per questo motivo, non essendovi nessuna necessità
+specifica di definirlo in fase di apertura del file, è sempre opportuno
+attivarlo in un secondo tempo con \func{fcntl} (vedi
+sez.~\ref{sec:file_fcntl_ioctl}).
+
+Il flag \const{O\_DIRECT} non è previsto da nessuno standard, anche se è
+presente in alcuni kernel unix-like.\footnote{il flag è stato introdotto dalla
+ SGI in IRIX, ma è presente senza limiti di allineamento dei buffer anche in
+ FreeBSD.} Per i kernel della serie 2.4 si deve garantire che i buffer in
+\textit{user space} da cui si effettua il trasferimento diretto dei dati siano
+allineati alle dimensioni dei blocchi del filesystem. Con il kernel 2.6 in
+genere basta che siano allineati a multipli di 512 byte, ma le restrizioni
+possono variare a seconda del filesystem, ed inoltre su alcuni filesystem
+questo flag può non essere supportato, nel qual caso si avrà un errore di
+\errval{EINVAL}.
+
+Lo scopo di \const{O\_DIRECT} è consentire un completo controllo sulla
+bufferizzazione dei propri dati per quelle applicazioni (in genere database)
+che hanno esigenze specifiche che non vengono soddisfatte nella maniera più
+efficiente dalla politica generica utilizzata dal kernel. In genere l'uso di
+questo flag peggiora le prestazioni tranne quando le applicazioni sono in
+grado di ottimizzare la propria bufferizzazione in maniera adeguata. Se lo si
+usa si deve avere cura di non mescolare questo tipo di accesso con quello
+ordinario, in quante le esigenze di mantenere coerenti i dati porterebbero ad
+un peggioramento delle prestazioni. Lo stesso dicasi per l'interazione con
+eventuale mappatura in memoria del file (vedi sez.~\ref{sec:file_memory_map}).
+
+Si tenga presente infine che anche se l'uso di \const{O\_DIRECT} comporta una
+scrittura sincrona dei dati dei buffer in \textit{user space}, questo non è
+completamente equivalente all'uso di \const{O\_SYNC} che garantisce anche
+sulla scrittura sincrona dei metadati associati alla scrittura dei dati del
+file.\footnote{la situazione si complica ulteriormente per NFS, in cui l'uso
+ del flag disabilita la bufferizzazione solo dal lato del client, e può
+ causare problemi di prestazioni.} Per questo in genere è opportuno se si usa
+\const{O\_DIRECT} è opportuno richiedere anche \const{O\_SYNC}.
+
+Si tenga presente infine che la implementazione di \const{O\_SYNC} di Linux
+differisce da quanto previsto dallo standard POSIX.1 che prevede, oltre a
+questo flag che dovrebbe indicare la sincronizzazione completa di tutti i dati
+e di tutti i metadati, altri due flag \const{O\_DSYNC} e \const{O\_RSYNC}.
+
+Il primo dei due richiede la scrittura sincrona di tutti i dati del file e dei
+metadati che ne consentono l'immediata rilettura, ma non di tutti i metadati,
+per evitare la perdita di prestazioni relativa alla sincronizzazione di
+informazioni ausiliarie come i tempi dei file. Il secondo, da usare in
+combinazione con \const{O\_SYNC} o \const{O\_DSYNC} ne sospende l'effetto,
+consentendo al kernel di bufferizzare le scritture, ma soltanto finché non
+avviene una lettura, in quel caso i dati ed i metadati dovranno essere
+sincronizzati immediatamente (secondo le modalità indicate da \const{O\_SYNC}
+e \const{O\_DSYNC}) e la lettura verrà bloccata fintanto che detta
+sincronizzazione non sia completata.
+
+Nel caso di Linux, fino al kernel 2.6.33, esisteva solo \const{O\_SYNC}, ma
+con il comportamento previsto dallo standard per \const{O\_DSYNC}, e sia
+questo che \const{O\_RSYNC} erano definiti (fin dal kernel 2.1.130) come
+sinonimi di \const{O\_SYNC}. Con il kernel 2.6.33 il significato di
+\const{O\_SYNC} è diventato quello dello standard, ma gli è stato assegnato un
+valore diverso, mantenendo quello originario, con il comportamento
+corrispondete, per \const{O\_DSYNC} in modo che applicazioni compilate con
+versioni precedenti delle librerie e del kernel non trovassero un
+comportamento diverso. Inoltre il nuovo \const{O\_SYNC} è stato definito in
+maniera opportuna in modo che su versioni del kernel precedenti la 2.6.33
+torni a corrispondere al valore di \const{O\_DSYNC}.
+
+% NOTE: per le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
+% nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/