3 %% Copyright (C) 2000-2006 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
11 \chapter{I file: l'interfaccia standard Unix}
12 \label{cha:file_unix_interface}
15 Esamineremo in questo capitolo la prima delle due interfacce di programmazione
16 per i file, quella dei \textit{file descriptor}\index{file!descriptor},
17 nativa di Unix. Questa è l'interfaccia di basso livello provvista direttamente
18 dalle system call, che non prevede funzionalità evolute come la
19 bufferizzazione o funzioni di lettura o scrittura formattata, e sulla quale è
20 costruita anche l'interfaccia definita dallo standard ANSI C che affronteremo
21 al cap.~\ref{cha:files_std_interface}.
25 \section{L'architettura di base}
26 \label{sec:file_base_arch}
28 In questa sezione faremo una breve introduzione sull'architettura su cui è
29 basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con
30 differenze nella realizzazione pratica, resta sostanzialmente la stessa in
31 tutte le implementazione di un sistema unix-like.
34 \subsection{L'architettura dei \textit{file descriptor}}
37 \index{file!descriptor|(}
39 Per poter accedere al contenuto di un file occorre
40 creare un canale di comunicazione con il kernel che renda possibile operare su
41 di esso (si ricordi quanto visto in sez.~\ref{sec:file_vfs_work}). Questo si
42 fa aprendo il file con la funzione \func{open} che provvederà a localizzare
43 l'inode\index{inode} del file e inizializzare i puntatori che rendono
44 disponibili le funzioni che il VFS mette a disposizione (riportate in
45 tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
46 file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
47 impedendo ogni ulteriore operazione.
49 All'interno di ogni processo i file aperti sono identificati da un intero non
50 negativo, chiamato appunto \textit{file descriptor}.
51 Quando un file viene aperto la funzione \func{open} restituisce questo numero,
52 tutte le ulteriori operazioni saranno compiute specificando questo stesso
53 valore come argomento alle varie funzioni dell'interfaccia.
55 Per capire come funziona il meccanismo occorre spiegare a grandi linee come il
56 kernel gestisce l'interazione fra processi e file. Il kernel mantiene sempre
57 un elenco dei processi attivi nella cosiddetta \itindex{process~table}
58 \textit{process table} ed un elenco dei file aperti nella \textit{file table}.
60 La \itindex{process~table} \textit{process table} è una tabella che contiene
61 una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è
62 costituita da una struttura di tipo \struct{task\_struct} nella quale sono
63 raccolte tutte le informazioni relative al processo; fra queste informazioni
64 c'è anche il puntatore ad una ulteriore struttura di tipo
65 \struct{files\_struct}, in cui sono contenute le informazioni relative ai file
66 che il processo ha aperto, ed in particolare:
68 \item i flag relativi ai file descriptor.
69 \item il numero di file aperti.
70 \item una tabella che contiene un puntatore alla relativa voce nella
71 \textit{file table} per ogni file aperto.
73 il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
76 La \textit{file table} è una tabella che contiene una voce per ciascun file
77 che è stato aperto nel sistema. In Linux è costituita da strutture di tipo
78 \struct{file}; in ciascuna di esse sono tenute varie informazioni relative al
81 \item lo stato del file (nel campo \var{f\_flags}).
82 \item il valore della posizione corrente (l'\textit{offset}) nel file (nel
84 \item un puntatore \index{inode} all'inode\footnote{nel kernel 2.4.x si è in
85 realtà passati ad un puntatore ad una struttura \struct{dentry} che punta a
86 sua volta all'inode\index{inode} passando per la nuova struttura del VFS.}
88 %\item un puntatore alla tabella delle funzioni \footnote{la struttura
89 % \var{f\_op} descritta in sez.~\ref{sec:file_vfs_work}} che si possono usare
93 In fig.~\ref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
94 questa architettura, ed in cui si sono evidenziate le interrelazioni fra le
95 varie strutture di dati sulla quale essa è basata.
96 Ritorneremo su questo schema più volte, dato che esso è fondamentale per
97 capire i dettagli del funzionamento dell'interfaccia dei \textit{file
99 \index{file!descriptor|)}
103 \includegraphics[width=13cm]{img/procfile}
104 \caption{Schema della architettura dell'accesso ai file attraverso
105 l'interfaccia dei \textit{file descriptor}.}
106 \label{fig:file_proc_file}
111 \subsection{I file standard}
112 \label{sec:file_std_descr}
114 Come accennato i \textit{file descriptor} non sono altro che un indice nella
115 tabella dei file aperti di ciascun processo; per questo motivo essi vengono
116 assegnati in successione tutte le volte che si apre un nuovo file (se non ne è
117 stato chiuso nessuno in precedenza).
119 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
120 processo viene lanciato dalla shell con almeno tre file aperti. Questi, per
121 quanto appena detto, avranno come \index{file!descriptor} \textit{file
122 descriptor} i valori 0, 1 e 2. Benché questa sia soltanto una convenzione,
123 essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe
124 portare a gravi problemi di interoperabilità.
126 Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
127 il file da cui il processo si aspetta di ricevere i dati in ingresso. Il
128 secondo file è il cosiddetto \textit{standard output}, cioè quello su cui ci
129 si aspetta debbano essere inviati i dati in uscita. Il terzo è lo
130 \textit{standard error}, su cui viene inviata l'uscita relativa agli errori.
131 Nel caso della shell tutti questi file sono associati al terminale di
132 controllo, e corrispondono quindi alla lettura della tastiera per l'ingresso e
133 alla scrittura sul terminale per l'uscita. Lo standard POSIX.1 provvede, al
134 posto dei valori numerici, tre costanti simboliche, definite in
135 tab.~\ref{tab:file_std_files}.
140 \begin{tabular}[c]{|l|l|}
142 \textbf{Costante} & \textbf{Significato} \\
145 \const{STDIN\_FILENO} & \textit{file descriptor} dello \textit{standard
147 \const{STDOUT\_FILENO} & \textit{file descriptor} dello \textit{standard
149 \const{STDERR\_FILENO} & \textit{file descriptor} dello \textit{standard
153 \caption{Costanti definite in \file{unistd.h} per i file standard aperti
154 alla creazione di ogni processo.}
155 \label{tab:file_std_files}
158 In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa,
159 facendo riferimento ad un programma in cui lo \textit{standard input} è
160 associato ad un file mentre lo \textit{standard output} e lo \textit{standard
161 error} sono entrambi associati ad un altro file (e quindi utilizzano lo
162 stesso inode\index{inode}).
164 Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
165 numero di file aperti era anche soggetto ad un limite massimo dato dalle
166 dimensioni del vettore di puntatori con cui era realizzata la tabella dei file
167 descriptor dentro \struct{file\_struct}; questo limite intrinseco nei kernel
168 più recenti non sussiste più, dato che si è passati da un vettore ad una
169 lista, ma restano i limiti imposti dall'amministratore (vedi
170 sez.~\ref{sec:sys_limits}).
174 \section{Le funzioni base}
175 \label{sec:file_base_func}
177 L'interfaccia standard Unix per l'input/output sui file è basata su cinque
178 funzioni fondamentali: \func{open}, \func{read}, \func{write}, \func{lseek} e
179 \func{close}, usate rispettivamente per aprire, leggere, scrivere, spostarsi e
180 chiudere un file. La gran parte delle operazioni sui file si effettua
181 attraverso queste cinque funzioni, esse vengono chiamate anche funzioni di I/O
182 non bufferizzato dato che effettuano le operazioni di lettura e scrittura
183 usando direttamente le system call del kernel.
186 \subsection{La funzione \func{open}}
187 \label{sec:file_open}
189 La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è
190 quella che crea l'associazione fra un \itindex{pathname}\textit{pathname} ed
191 un file descriptor, il suo prototipo è:
193 \headdecl{sys/types.h}
194 \headdecl{sys/stat.h}
196 \funcdecl{int open(const char *pathname, int flags)}
197 \funcdecl{int open(const char *pathname, int flags, mode\_t mode)}
198 Apre il file indicato da \param{pathname} nella modalità indicata da
199 \param{flags}, e, nel caso il file sia creato, con gli eventuali permessi
200 specificati da \param{mode}.
202 \bodydesc{La funzione ritorna il file descriptor in caso di successo e $-1$
203 in caso di errore. In questo caso la variabile \var{errno} assumerà uno
206 \item[\errcode{EEXIST}] \param{pathname} esiste e si è specificato
207 \const{O\_CREAT} e \const{O\_EXCL}.
208 \item[\errcode{EISDIR}] \param{pathname} indica una directory e si è tentato
209 l'accesso in scrittura.
210 \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
211 \param{pathname} non è una directory.
212 \item[\errcode{ENXIO}] si sono impostati \const{O\_NOBLOCK} o
213 \const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
214 processo o \param{pathname} è un file di dispositivo ma il dispositivo è
216 \item[\errcode{ENODEV}] \param{pathname} si riferisce a un file di
217 dispositivo che non esiste.
218 \item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
219 di un programma in esecuzione.
220 \item[\errcode{ELOOP}] si sono incontrati troppi link simbolici nel
221 risolvere il \textit{pathname} o si è indicato \const{O\_NOFOLLOW} e
222 \param{pathname} è un link simbolico.
224 ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOENT},
225 \errval{EROFS}, \errval{EFAULT}, \errval{ENOSPC}, \errval{ENOMEM},
226 \errval{EMFILE} e \errval{ENFILE}.}
230 La funzione apre il file usando il primo file descriptor libero, e crea
231 l'opportuna voce, cioè la struttura \struct{file}, nella \textit{file table}
232 del processo. Viene sempre restituito come valore di ritorno il file
233 descriptor con il valore più basso disponibile.
235 \footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
236 opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
237 \textsl{file di lock}\index{file!di lock} possono incorrere in una
238 \textit{race condition}\itindex{race~condition}. Si consiglia come
239 alternativa di usare un file con un nome univoco e la funzione \func{link}
240 per verificarne l'esistenza (vedi sez.~\ref{sec:ipc_file_lock}).}
242 \footnotetext[3]{acronimo di \textit{Denial of
243 Service}\itindex{Denial~of~Service~(DoS)}, si chiamano così attacchi
244 miranti ad impedire un servizio causando una qualche forma di carico
245 eccessivo per il sistema, che resta bloccato nelle risposte all'attacco.}
250 \begin{tabular}[c]{|l|p{12cm}|}
252 \textbf{Flag} & \textbf{Descrizione} \\
254 \hline % modalità di accesso al file
255 \const{O\_RDONLY} & Apre il file in sola lettura, le \acr{glibc}
256 definiscono anche \const{O\_READ} come sinonimo. \\
257 \const{O\_WRONLY} & Apre il file in sola scrittura, le \acr{glibc}
258 definiscono anche \const{O\_WRITE} come sinonimo. \\
259 \const{O\_RDWR} & Apre il file sia in lettura che in scrittura. \\
260 \hline % modalità di apertura del file
262 \const{O\_CREAT} & Se il file non esiste verrà creato, con le regole di
263 titolarità del file viste in
264 sez.~\ref{sec:file_ownership}. Con questa opzione
265 l'argomento \param{mode} deve essere specificato. \\
266 \const{O\_EXCL} & Usato in congiunzione con \const{O\_CREAT} fa sì che
267 la precedente esistenza del file diventi un
268 errore\protect\footnotemark\ che fa fallire
269 \func{open} con \errcode{EEXIST}. \\
270 \const{O\_NONBLOCK}& Apre il file in modalità non bloccante, e
271 comporta che \func{open} ritorni immediatamente anche
272 quando dovrebbe bloccarsi (l'opzione ha senso solo per
273 le fifo, vedi sez.~\ref{sec:ipc_named_pipe}). \\
274 \const{O\_NOCTTY} & Se \param{pathname} si riferisce ad un dispositivo di
275 terminale, questo non diventerà il terminale di
276 controllo, anche se il processo non ne ha ancora uno
277 (si veda sez.~\ref{sec:sess_ctrl_term}). \\
278 \const{O\_SHLOCK} & Apre il file con uno shared lock (vedi
279 sez.~\ref{sec:file_locking}). Specifica di BSD,
281 \const{O\_EXLOCK} & Apre il file con un lock esclusivo (vedi
282 sez.~\ref{sec:file_locking}). Specifica di BSD,
284 \const{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
285 ne tronca la lunghezza a zero; con un terminale o una
286 fifo viene ignorato, negli altri casi il
287 comportamento non è specificato. \\
288 \const{O\_NOFOLLOW}& Se \param{pathname} è un link simbolico la chiamata
289 fallisce. Questa è un'estensione BSD aggiunta in Linux
290 dal kernel 2.1.126. Nelle versioni precedenti i link
291 simbolici sono sempre seguiti, e questa opzione è
293 \const{O\_DIRECTORY}&Se \param{pathname} non è una directory la chiamata
294 fallisce. Questo flag è specifico di Linux ed è stato
295 introdotto con il kernel 2.1.126 per evitare dei
296 \itindex{Denial~of~Service~(DoS)}
297 \textit{DoS}\protect\footnotemark\ quando
298 \func{opendir} viene chiamata su una fifo o su un
299 dispositivo associato ad una unità a nastri, non deve
300 dispositivo a nastri; non deve essere utilizzato
301 al di fuori dell'implementazione di \func{opendir}. \\
302 \const{O\_LARGEFILE}&nel caso di sistemi a 32 bit che supportano file di
303 grandi dimensioni consente di aprire file le cui
304 dimensioni non possono essere rappresentate da numeri
307 \hline % modalità di operazione coi file
308 \const{O\_APPEND} & Il file viene aperto in \itindex{append~mode}
309 \textit{append mode}. Prima di ciascuna
310 scrittura la posizione corrente viene sempre impostata
311 alla fine del file. Con NFS si può avere una
312 corruzione del file se più di un processo scrive allo
313 stesso tempo.\footnotemark\\
314 \const{O\_NONBLOCK}& Il file viene aperto in modalità non bloccante per
315 le operazioni di I/O (che tratteremo in
316 sez.~\ref{sec:file_noblocking}): questo significa il
317 fallimento di \func{read} in assenza di dati da
318 leggere e quello di \func{write} in caso di
319 impossibilità di scrivere immediatamente. Questa
320 modalità ha senso solo per le fifo e per alcuni file
322 \const{O\_NDELAY} & In Linux\footnotemark\ è sinonimo di
323 \const{O\_NONBLOCK}.\\
324 \const{O\_ASYNC} & Apre il file per l'I/O in modalità asincrona (vedi
325 sez.~\ref{sec:file_asyncronous_io}). Quando è
326 impostato viene generato il segnale \const{SIGIO}
327 tutte le volte che sono disponibili dati in input
329 \const{O\_SYNC} & Apre il file per l'input/output sincrono: ogni
330 \func{write} bloccherà fino al completamento della
331 scrittura di tutti i dati sull'hardware
333 \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}, usato da BSD. \\
334 \const{O\_DSYNC} & Variante di I/O sincrono definita da POSIX; presente
335 dal kernel 2.1.130 come sinonimo di
337 \const{O\_RSYNC} & Variante analoga alla precedente, trattata allo stesso
339 \const{O\_NOATIME} & Blocca l'aggiornamento dei tempi di accesso dei
340 file (vedi sez.~\ref{sec:file_file_times}). Per molti
341 filesystem questa funzionalità non è disponibile per
342 il singolo file ma come opzione generale da
343 specificare in fase di montaggio.\\
344 \const{O\_DIRECT} & Esegue l'I/O direttamente dai buffer in user space
345 in maniera sincrona, in modo da scavalcare i
346 meccanismi di caching del kernel. In genere questo
347 peggiora le prestazioni tranne quando le
348 applicazioni\footnotemark ottimizzano il proprio
349 caching. Per i kernel della serie 2.4 si deve
350 garantire che i buffer in user space siano allineati
351 alle dimensioni dei blocchi del filesystem; per il
352 kernel 2.6 basta che siano allineati a multipli di 512
356 \caption{Valori e significato dei vari bit del \textit{file status flag}.}
357 \label{tab:file_open_flags}
360 \footnotetext[4]{il problema è che NFS non supporta la scrittura in
361 \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma
362 questo comporta la possibilità di una \itindex{race~condition} \textit{race
363 condition}, vedi sez.~\ref{sec:file_atomic}.}
365 \footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
366 una \func{read} con un valore nullo e non con un errore, questo introduce
367 un'ambiguità, dato che come vedremo in sez.~\ref{sec:file_read} il ritorno di
368 zero da parte di \func{read} ha il significato di una end-of-file.}
370 \footnotetext[6]{l'opzione è stata introdotta dalla SGI in IRIX, e serve
371 sostanzialmente a permettere ad alcuni programmi (in genere database) la
372 gestione diretta della bufferizzazione dell'I/O in quanto essi sono in grado
373 di ottimizzarla al meglio per le loro prestazioni; l'opzione è presente
374 anche in FreeBSD, senza limiti di allineamento dei buffer. In Linux è stata
375 introdotta con il kernel 2.4.10, le versioni precedenti la ignorano.}
378 Questa caratteristica permette di prevedere qual è il valore del file
379 descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
380 alcune applicazioni per sostituire i file corrispondenti ai file standard
381 visti in sez.~\ref{sec:file_std_descr}: se ad esempio si chiude lo standard
382 input e si apre subito dopo un nuovo file questo diventerà il nuovo standard
383 input (avrà cioè il file descriptor 0).
385 Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo
386 sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
387 sez.~\ref{sec:file_sharing}) ed è impostato per restare aperto attraverso una
388 \func{exec} (come accennato in sez.~\ref{sec:proc_exec}); l'offset è impostato
391 L'argomento \param{mode} indica i permessi con cui il file viene creato; i
392 valori possibili sono gli stessi già visti in sez.~\ref{sec:file_perm_overview}
393 e possono essere specificati come OR binario delle costanti descritte in
394 tab.~\ref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di
395 \var{umask} (vedi sez.~\ref{sec:file_umask}) per il processo.
397 La funzione prevede diverse opzioni, che vengono specificate usando vari bit
398 dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire
399 il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
400 campo \var{f\_flags} della struttura \struct{file} (al solito si veda lo schema
401 di fig.~\ref{fig:file_proc_file}). Essi sono divisi in tre categorie
404 \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
405 si accederà al file: i valori possibili sono lettura, scrittura o
406 lettura/scrittura. Uno di questi bit deve essere sempre specificato quando
407 si apre un file. Vengono impostati alla chiamata da \func{open}, e possono
408 essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}),
409 ma non possono essere modificati.
410 \item \textsl{i bit delle modalità di apertura}: permettono di specificare
411 alcune delle caratteristiche del comportamento di \func{open} quando viene
412 eseguita. Hanno effetto solo al momento della chiamata della funzione e non
413 sono memorizzati né possono essere riletti.
414 \item \textsl{i bit delle modalità di operazione}: permettono di specificare
415 alcune caratteristiche del comportamento delle future operazioni sul file
416 (come \func{read} o \func{write}). Anch'essi fan parte del \textit{file
417 status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma
418 possono essere riletti e modificati (insieme alle caratteristiche operative
419 che controllano) con una \func{fcntl}.
422 In tab.~\ref{tab:file_open_flags} sono riportate, ordinate e divise fra loro
423 secondo le tre modalità appena elencate, le costanti mnemoniche associate a
424 ciascuno di questi bit. Dette costanti possono essere combinate fra loro con
425 un OR aritmetico per costruire il valore (in forma di maschera binaria)
426 dell'argomento \param{flags} da passare alla \func{open}. I due flag
427 \const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono estensioni specifiche di
428 Linux, e deve essere definita la macro \macro{\_GNU\_SOURCE} per poterli
431 Nelle prime versioni di Unix i valori di \param{flag} specificabili per
432 \func{open} erano solo quelli relativi alle modalità di accesso del file. Per
433 questo motivo per creare un nuovo file c'era una system call apposita,
434 \funcd{creat}, il cui prototipo è:
435 \begin{prototype}{fcntl.h}
436 {int creat(const char *pathname, mode\_t mode)}
437 Crea un nuovo file vuoto, con i permessi specificati da \param{mode}. È del
438 tutto equivalente a \code{open(filedes, O\_CREAT|O\_WRONLY|O\_TRUNC, mode)}.
440 \noindent adesso questa funzione resta solo per compatibilità con i vecchi
444 \subsection{La funzione \func{close}}
445 \label{sec:file_close}
447 La funzione \funcd{close} permette di chiudere un file, in questo modo il file
448 descriptor ritorna disponibile; il suo prototipo è:
449 \begin{prototype}{unistd.h}{int close(int fd)}
450 Chiude il descrittore \param{fd}.
452 \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
453 errore, con \var{errno} che assume i valori:
455 \item[\errcode{EBADF}] \param{fd} non è un descrittore valido.
456 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
458 ed inoltre \errval{EIO}.}
461 La chiusura di un file rilascia ogni blocco (il \textit{file locking}
462 \index{file!locking} è trattato in sez.~\ref{sec:file_locking}) che il
463 processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
464 riferimento (di eventuali copie) ad un file aperto, tutte le risorse nella
465 file table vengono rilasciate. Infine se il file descriptor era l'ultimo
466 riferimento ad un file su disco quest'ultimo viene cancellato.
468 Si ricordi che quando un processo termina anche tutti i suoi file descriptor
469 vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
470 esplicitamente \func{close}. In genere comunque chiudere un file senza
471 controllarne lo stato di uscita è errore; infatti molti filesystem
472 implementano la tecnica del \textit{write-behind}, per cui una \func{write}
473 può avere successo anche se i dati non sono stati scritti, un eventuale errore
474 di I/O allora può sfuggire, ma verrà riportato alla chiusura del file: per
475 questo motivo non effettuare il controllo può portare ad una perdita di dati
476 inavvertita.\footnote{in Linux questo comportamento è stato osservato con NFS
477 e le quote su disco.}
479 In ogni caso una \func{close} andata a buon fine non garantisce che i dati
480 siano stati effettivamente scritti su disco, perché il kernel può decidere di
481 ottimizzare l'accesso a disco ritardandone la scrittura. L'uso della funzione
482 \func{sync} (vedi sez.~\ref{sec:file_sync}) effettua esplicitamente il
483 \emph{flush} dei dati, ma anche in questo caso resta l'incertezza dovuta al
484 comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
485 dell'accesso al disco che ritardano la scrittura dei dati, da cui l'abitudine
486 di ripetere tre volte il comando prima di eseguire lo shutdown).
489 \subsection{La funzione \func{lseek}}
490 \label{sec:file_lseek}
492 Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
493 una \textsl{posizione corrente nel file} (il cosiddetto \textit{file offset},
494 mantenuto nel campo \var{f\_pos} di \struct{file}) espressa da un numero intero
495 positivo come numero di byte dall'inizio del file. Tutte le operazioni di
496 lettura e scrittura avvengono a partire da questa posizione che viene
497 automaticamente spostata in avanti del numero di byte letti o scritti.
499 In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
500 \const{O\_APPEND}) questa posizione viene impostata a zero all'apertura del
501 file. È possibile impostarla ad un valore qualsiasi con la funzione
502 \funcd{lseek}, il cui prototipo è:
504 \headdecl{sys/types.h}
506 \funcdecl{off\_t lseek(int fd, off\_t offset, int whence)}
507 Imposta la posizione attuale nel file.
509 \bodydesc{La funzione ritorna il valore della posizione corrente in caso di
510 successo e $-1$ in caso di errore nel qual caso \var{errno} assumerà uno
513 \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
514 \item[\errcode{EINVAL}] \param{whence} non è un valore valido.
516 ed inoltre \errval{EBADF}.}
519 La nuova posizione è impostata usando il valore specificato da \param{offset},
520 sommato al riferimento dato da \param{whence}; quest'ultimo può assumere i
521 seguenti valori\footnote{per compatibilità con alcune vecchie notazioni
522 questi valori possono essere rimpiazzati rispettivamente con 0, 1 e 2 o con
523 \const{L\_SET}, \const{L\_INCR} e \const{L\_XTND}.}:
524 \begin{basedescript}{\desclabelwidth{2.0cm}}
525 \item[\const{SEEK\_SET}] si fa riferimento all'inizio del file: il valore
526 (sempre positivo) di \param{offset} indica direttamente la nuova posizione
528 \item[\const{SEEK\_CUR}] si fa riferimento alla posizione corrente del file:
529 ad essa viene sommato \param{offset} (che può essere negativo e positivo)
530 per ottenere la nuova posizione corrente.
531 \item[\const{SEEK\_END}] si fa riferimento alla fine del file: alle dimensioni
532 del file viene sommato \param{offset} (che può essere negativo e positivo)
533 per ottenere la nuova posizione corrente.
536 Come accennato in sez.~\ref{sec:file_file_size} con \func{lseek} è possibile
537 impostare la posizione corrente anche oltre la fine del file, e alla
538 successiva scrittura il file sarà esteso. La chiamata non causa nessun accesso
539 al file, si limita a modificare la posizione corrente (cioè il valore
540 \var{f\_pos} in \param{file}, vedi fig.~\ref{fig:file_proc_file}). Dato che la
541 funzione ritorna la nuova posizione, usando il valore zero per \param{offset}
542 si può riottenere la posizione corrente nel file chiamando la funzione con
543 \code{lseek(fd, 0, SEEK\_CUR)}.
545 Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che
546 la successiva scrittura avvenga alla fine del file, infatti se questo è stato
547 aperto anche da un altro processo che vi ha scritto, la fine del file può
548 essersi spostata, ma noi scriveremo alla posizione impostata in precedenza
549 (questa è una potenziale sorgente di \itindex{race~condition}\textit{race
550 condition}, vedi sez.~\ref{sec:file_atomic}).
552 Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
553 questo caso la funzione ritorna l'errore \errcode{EPIPE}. Questo, oltre che per
554 i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che non
555 supportano questa funzione, come ad esempio per i file di
556 terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
557 ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
558 POSIX però non specifica niente in proposito. Infine alcuni file speciali, ad
559 esempio \file{/dev/null}, non causano un errore ma restituiscono un valore
563 \subsection{La funzione \func{read}}
564 \label{sec:file_read}
567 Una volta che un file è stato aperto (con il permesso in lettura) si possono
568 leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui
570 \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
572 Cerca di leggere \param{count} byte dal file \param{fd} al buffer
575 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
576 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
578 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
579 aver potuto leggere qualsiasi dato.
580 \item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
581 era aperto il file in modalità \const{O\_NONBLOCK}.
583 ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
584 \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori dipendenti dalla
585 natura dell'oggetto connesso a \param{fd}.}
588 La funzione tenta di leggere \param{count} byte a partire dalla posizione
589 corrente nel file. Dopo la lettura la posizione sul file è spostata
590 automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
591 funzione restituisce zero senza nessun altro risultato. Si deve sempre tener
592 presente che non è detto che la funzione \func{read} restituisca sempre il
593 numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione
594 può restituire un numero di byte inferiore; questo è un comportamento normale,
595 e non un errore, che bisogna sempre tenere presente.
597 La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
598 di quanto il file ne contenga. In questo caso il file viene letto fino alla
599 sua fine, e la funzione ritorna regolarmente il numero di byte letti
600 effettivamente. Raggiunta la fine del file, alla ripetizione di un'operazione
601 di lettura, otterremmo il ritorno immediato di \func{read} con uno zero. La
602 condizione di raggiungimento della fine del file non è un errore, e viene
603 segnalata appunto da un valore di ritorno di \func{read} nullo. Ripetere
604 ulteriormente la lettura non avrebbe nessun effetto se non quello di
605 continuare a ricevere zero come valore di ritorno.
607 Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
608 un numero di byte letti inferiore a quello richiesto, ma questo non è vero
609 quando si legge da un terminale, da una fifo o da una pipe. In tal caso
610 infatti, se non ci sono dati in ingresso, la \func{read} si blocca (a meno di
611 non aver selezionato la modalità non bloccante, vedi
612 sez.~\ref{sec:file_noblocking}) e ritorna solo quando ne arrivano; se il numero
613 di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma
614 con un numero di byte inferiore a quelli richiesti.
616 Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
617 come vedremo in sez.~\ref{sec:sock_io_behav}), o per la lettura da certi file
618 di dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
619 singolo blocco alla volta, o come le linee seriali, che restituiscono solo i
620 dati ricevuti fino al momento della lettura.
622 Infine anche le due condizioni segnalate dagli errori \errcode{EINTR} ed
623 \errcode{EAGAIN} non sono propriamente degli errori. La prima si verifica
624 quando la \func{read} è bloccata in attesa di dati in ingresso e viene
625 interrotta da un segnale; in tal caso l'azione da intraprendere è quella di
626 rieseguire la funzione. Torneremo in dettaglio sull'argomento in
627 sez.~\ref{sec:sig_gen_beha}. La seconda si verifica quando il file è aperto
628 in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
629 dati in ingresso: la funzione allora ritorna immediatamente con un errore
630 \errcode{EAGAIN}\footnote{BSD usa per questo errore la costante
631 \errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
632 \errcode{EAGAIN}.} che indica soltanto che non essendoci al momento dati
633 disponibili occorre provare a ripetere la lettura in un secondo tempo.
635 La funzione \func{read} è una delle system call fondamentali, esistenti fin
636 dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix
637 Specification}\footnote{questa funzione, e l'analoga \func{pwrite} sono
638 state aggiunte nel kernel 2.1.60, il supporto nelle \acr{glibc}, compresa
639 l'emulazione per i vecchi kernel che non hanno la system call, è stato
640 aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
641 delle librerie la funzione non è disponibile.} (quello che viene chiamato
642 normalmente Unix98, vedi sez.~\ref{sec:intro_opengroup}) è stata introdotta la
643 definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
644 \begin{prototype}{unistd.h}
645 {ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
647 Cerca di leggere \param{count} byte dal file \param{fd}, a partire dalla
648 posizione \param{offset}, nel buffer \param{buf}.
650 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
651 $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
652 visti per \func{read} e \func{lseek}.}
655 La funzione prende esattamente gli stessi argomenti di \func{read} con lo
656 stesso significato, a cui si aggiunge l'argomento \func{offset} che indica una
657 posizione sul file. Identico è il comportamento ed il valore di ritorno. La
658 funzione serve quando si vogliono leggere dati dal file senza modificare la
661 L'uso di \func{pread} è equivalente all'esecuzione di una \func{read} seguita
662 da una \func{lseek} che riporti al valore precedente la posizione corrente sul
663 file, ma permette di eseguire l'operazione atomicamente. Questo può essere
664 importante quando la posizione sul file viene condivisa da processi diversi
665 (vedi sez.~\ref{sec:file_sharing}). Il valore di
666 \param{offset} fa sempre riferimento all'inizio del file.
668 La funzione \func{pread} è disponibile anche in Linux, però diventa
669 accessibile solo attivando il supporto delle estensioni previste dalle
670 \textit{Single Unix Specification} con la definizione della macro:
672 #define _XOPEN_SOURCE 500
674 e si ricordi di definire questa macro prima dell'inclusione del file di
675 dichiarazioni \file{unistd.h}.
679 \subsection{La funzione \func{write}}
680 \label{sec:file_write}
682 Una volta che un file è stato aperto (con il permesso in scrittura) si può
683 scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
684 \begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
686 Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}.
688 \bodydesc{La funzione ritorna il numero di byte scritti in caso di successo
689 e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
692 \item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
694 \item[\errcode{EFBIG}] si è cercato di scrivere oltre la dimensione massima
695 consentita dal filesystem o il limite per le dimensioni dei file del
696 processo o su una posizione oltre il massimo consentito.
697 \item[\errcode{EPIPE}] \param{fd} è connesso ad una pipe il cui altro capo è
698 chiuso in lettura; in questo caso viene anche generato il segnale
699 \const{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
700 funzione ritorna questo errore.
701 \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
702 potuto scrivere qualsiasi dato.
703 \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
704 modalità \const{O\_NONBLOCK}.
706 ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
707 \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori
708 dipendenti dalla natura dell'oggetto connesso a \param{fd}.}
711 Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
712 a partire dalla posizione corrente nel file e sposta automaticamente la
713 posizione in avanti del numero di byte scritti. Se il file è aperto in
714 modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
715 alla fine del file. Lo standard POSIX richiede che i dati scritti siano
716 immediatamente disponibili ad una \func{read} chiamata dopo che la
717 \func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
718 non è detto che tutti i filesystem supportino questa capacità.
720 Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
721 Per i file ordinari il numero di byte scritti è sempre uguale a quello
722 indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
723 stesso comportamento di \func{read}.
725 Anche per \func{write} lo standard Unix98 definisce un'analoga \funcd{pwrite}
726 per scrivere alla posizione indicata senza modificare la posizione corrente
727 nel file, il suo prototipo è:
728 \begin{prototype}{unistd.h}
729 {ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)}
731 Cerca di scrivere sul file \param{fd}, a partire dalla posizione
732 \param{offset}, \param{count} byte dal buffer \param{buf}.
734 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
735 $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
736 visti per \func{write} e \func{lseek}.}
738 \noindent e per essa valgono le stesse considerazioni fatte per \func{pread}.
741 \section{Caratteristiche avanzate}
742 \label{sec:file_adv_func}
744 In questa sezione approfondiremo alcune delle caratteristiche più sottili
745 della gestione file in un sistema unix-like, esaminando in dettaglio il
746 comportamento delle funzioni base, inoltre tratteremo le funzioni che
747 permettono di eseguire alcune operazioni avanzate con i file (il grosso
748 dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
751 \subsection{La condivisione dei files}
752 \label{sec:file_sharing}
754 In sez.~\ref{sec:file_fd} abbiamo descritto brevemente l'architettura
755 dell'interfaccia con i file da parte di un processo, mostrando in
756 fig.~\ref{fig:file_proc_file} le principali strutture usate dal kernel;
757 esamineremo ora in dettaglio le conseguenze che questa architettura ha nei
758 confronti dell'accesso allo stesso file da parte di processi diversi.
762 \includegraphics[width=15cm]{img/filemultacc}
763 \caption{Schema dell'accesso allo stesso file da parte di due processi
765 \label{fig:file_mult_acc}
768 Il primo caso è quello in cui due processi diversi aprono lo stesso file
769 su disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
770 situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
771 processo avrà una sua voce nella \textit{file table} referenziata da un
772 diverso file descriptor nella sua \struct{file\_struct}. Entrambe le voci
773 nella \textit{file table} faranno però riferimento allo stesso
774 inode\index{inode} su disco.
776 Questo significa che ciascun processo avrà la sua posizione corrente sul file,
777 la sua modalità di accesso e versioni proprie di tutte le proprietà che
778 vengono mantenute nella sua voce della \textit{file table}. Questo ha
779 conseguenze specifiche sugli effetti della possibile azione simultanea sullo
780 stesso file, in particolare occorre tenere presente che:
782 \item ciascun processo può scrivere indipendentemente; dopo ciascuna
783 \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
784 scrittura eccede la dimensione corrente del file questo verrà esteso
785 automaticamente con l'aggiornamento del campo \var{i\_size}
786 nell'inode\index{inode}.
787 \item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
788 le volte che viene effettuata una scrittura la posizione corrente viene
789 prima impostata alla dimensione corrente del file letta
790 dall'inode\index{inode}. Dopo la scrittura il file viene automaticamente
792 \item l'effetto di \func{lseek} è solo quello di cambiare il campo
793 \var{f\_pos} nella struttura \struct{file} della \textit{file table}, non
794 c'è nessuna operazione sul file su disco. Quando la si usa per porsi alla
795 fine del file la posizione viene impostata leggendo la dimensione corrente
796 dall'inode\index{inode}.
801 \includegraphics[width=15cm]{img/fileshar}
802 \caption{Schema dell'accesso ai file da parte di un processo figlio}
803 \label{fig:file_acc_child}
806 Il secondo caso è quello in cui due file descriptor di due processi diversi
807 puntino alla stessa voce nella \textit{file table}; questo è ad esempio il
808 caso dei file aperti che vengono ereditati dal processo figlio all'esecuzione
809 di una \func{fork} (si ricordi quanto detto in sez.~\ref{sec:proc_fork}). La
810 situazione è illustrata in fig.~\ref{fig:file_acc_child}; dato che il processo
811 figlio riceve una copia dello spazio di indirizzi del padre, riceverà anche
812 una copia di \struct{file\_struct} e relativa tabella dei file aperti.
814 In questo modo padre e figlio avranno gli stessi file descriptor che faranno
815 riferimento alla stessa voce nella \textit{file table}, condividendo così la
816 posizione corrente sul file. Questo ha le conseguenze descritte a suo tempo in
817 sez.~\ref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
818 corrente nel file varierà per entrambi i processi (in quanto verrà modificato
819 \var{f\_pos} che è lo stesso per entrambi).
821 Si noti inoltre che anche i flag di stato del file (quelli impostati
822 dall'argomento \param{flag} di \func{open}) essendo tenuti nella voce della
823 \textit{file table}\footnote{per la precisione nel campo \var{f\_flags} di
824 \struct{file}.}, vengono in questo caso condivisi. Ai file però sono
825 associati anche altri flag, dei quali l'unico usato al momento è
826 \const{FD\_CLOEXEC}, detti \textit{file descriptor flags}. Questi ultimi sono
827 tenuti invece in \struct{file\_struct}, e perciò sono specifici di ciascun
828 processo e non vengono modificati dalle azioni degli altri anche in caso di
829 condivisione della stessa voce della \textit{file table}.
833 \subsection{Operazioni atomiche con i file}
834 \label{sec:file_atomic}
836 Come si è visto in un sistema unix-like è sempre possibile per più processi
837 accedere in contemporanea allo stesso file, e che le operazioni di lettura e
838 scrittura possono essere fatte da ogni processo in maniera autonoma in base
839 ad una posizione corrente nel file che è locale a ciascuno di essi.
841 Se dal punto di vista della lettura dei dati questo non comporta nessun
842 problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
843 maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
844 di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
845 utilizzare meccanismi di sincronizzazione più complessi (come il
846 \index{file!locking} \textit{file locking}, che esamineremo in
847 sez.~\ref{sec:file_locking}).
849 Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
850 vari processi devono scrivere alla fine di un file (ad esempio un file di
851 log). Come accennato in sez.~\ref{sec:file_lseek} impostare la posizione alla
852 fine del file e poi scrivere può condurre ad una
853 \itindex{race~condition}\textit{race condition}: infatti può succedere che un
854 secondo processo scriva alla fine del file fra la \func{lseek} e la
855 \func{write}; in questo caso, come abbiamo appena visto, il file sarà esteso,
856 ma il nostro primo processo avrà ancora la posizione corrente impostata con la
857 \func{lseek} che non corrisponde più alla fine del file, e la successiva
858 \func{write} sovrascriverà i dati del secondo processo.
860 Il problema è che usare due system call in successione non è un'operazione
861 atomica; il problema è stato risolto introducendo la modalità
862 \itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
863 descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
864 alla fine del file prima di effettuare la scrittura, e poi estende il file.
865 Tutto questo avviene all'interno di una singola system call (la \func{write})
866 che non essendo interrompibile da un altro processo costituisce un'operazione
869 Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
870 creare un \textsl{file di lock}\index{file!di lock}, bloccandosi se il file
871 esiste. In questo caso la sequenza logica porterebbe a verificare prima
872 l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
873 di nuovo avremmo la possibilità di una \textit{race
874 condition}\itindex{race~condition} da parte di un altro processo che crea lo
875 stesso file fra il controllo e la creazione.
877 Per questo motivo sono stati introdotti per \func{open} i due flag
878 \const{O\_CREAT} e \const{O\_EXCL}. In questo modo l'operazione di controllo
879 dell'esistenza del file (con relativa uscita dalla funzione con un errore) e
880 creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno
881 di una singola system call (per i dettagli sull'uso di questa caratteristica
882 si veda sez.~\ref{sec:ipc_file_lock}).
885 \subsection{La funzioni \func{sync} e \func{fsync}}
886 \label{sec:file_sync}
888 Come accennato in sez.~\ref{sec:file_close} tutte le operazioni di scrittura
889 sono in genere bufferizzate dal kernel, che provvede ad effettuarle in maniera
890 asincrona (ad esempio accorpando gli accessi alla stessa zona del disco) in un
891 secondo tempo rispetto al momento della esecuzione della \func{write}.
893 Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
894 sistema mette a disposizione delle funzioni che provvedono a forzare lo
895 scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
896 questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
897 l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
898 ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
899 scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
901 \begin{prototype}{unistd.h}{int sync(void)}
903 Sincronizza il buffer della cache dei file col disco.
905 \bodydesc{La funzione ritorna sempre zero.}
907 \noindent i vari standard prevedono che la funzione si limiti a far partire
908 le operazioni, ritornando immediatamente; in Linux (dal kernel 1.3.20) invece
909 la funzione aspetta la conclusione delle operazioni di sincronizzazione del
912 La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
913 esplicitamente lo scarico dei dati su disco, o dal demone di sistema
914 \cmd{update} che esegue lo scarico dei dati ad intervalli di tempo fissi: il
915 valore tradizionale, usato da BSD, per l'update dei dati è ogni 30 secondi, ma
916 in Linux il valore utilizzato è di 5 secondi; con le nuove versioni\footnote{a
917 partire dal kernel 2.2.8} poi, è il kernel che si occupa direttamente di
918 tutto quanto attraverso il demone interno \cmd{bdflush}, il cui comportamento
919 può essere controllato attraverso il file \file{/proc/sys/vm/bdflush} (per il
920 significato dei valori si può leggere la documentazione allegata al kernel in
921 \file{Documentation/sysctl/vm.txt}).
923 Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
924 sicuri che i dati di un database sono stati registrati su disco) si possono
925 usare le due funzioni \funcd{fsync} e \funcd{fdatasync}, i cui prototipi sono:
928 \funcdecl{int fsync(int fd)}
929 Sincronizza dati e metadati del file \param{fd}
930 \funcdecl{int fdatasync(int fd)}
931 Sincronizza i dati del file \param{fd}.
933 \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
934 errore, nel qual caso \var{errno} assume i valori:
936 \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
939 ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO}.}
942 Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
943 file specificato, ed attendono fino alla conclusione delle operazioni;
944 \func{fsync} forza anche la sincronizzazione dei metadati del file (che
945 riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
946 altri dati contenuti nell'inode\index{inode} che si leggono con \func{fstat},
947 come i tempi del file).
949 Si tenga presente che questo non comporta la sincronizzazione della
950 directory che contiene il file (e scrittura della relativa voce su
951 disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
952 il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
953 il kernel provvede anche alla sincronizzazione automatica delle voci
957 \subsection{La funzioni \func{dup} e \func{dup2}}
960 Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
961 condivida gli stessi file descriptor del padre; è possibile però ottenere un
962 comportamento analogo all'interno di uno stesso processo \textit{duplicando}
963 un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui
965 \begin{prototype}{unistd.h}{int dup(int oldfd)}
966 Crea una copia del file descriptor \param{oldfd}.
968 \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
969 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
972 \item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
973 \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
978 La funzione ritorna, come \func{open}, il primo file descriptor libero. Il
979 file descriptor è una copia esatta del precedente ed entrambi possono essere
980 interscambiati nell'uso. Per capire meglio il funzionamento della funzione si
981 può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
982 semplicemente quello di copiare il valore nella struttura
983 \struct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
984 alla stessa voce nella \textit{file table}; per questo si dice che il nuovo
985 file descriptor è \textsl{duplicato}, da cui il nome della funzione.
988 \centering \includegraphics[width=15cm]{img/filedup}
989 \caption{Schema dell'accesso ai file duplicati}
993 Si noti che per quanto illustrato in fig.~\ref{fig:file_dup} i file descriptor
994 duplicati condivideranno eventuali lock, \textit{file status flag}, e
995 posizione corrente. Se ad esempio si esegue una \func{lseek} per modificare la
996 posizione su uno dei due file descriptor, essa risulterà modificata anche
997 sull'altro (dato che quello che viene modificato è lo stesso campo nella voce
998 della \textit{file table} a cui entrambi fanno riferimento). L'unica
999 differenza fra due file descriptor duplicati è che ciascuno avrà il suo
1000 \textit{file descriptor flag}; a questo proposito va specificato che nel caso
1001 di \func{dup} il flag di \textit{close-on-exec}\itindex{close-on-exec} (vedi
1002 sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl}) viene sempre cancellato
1005 L'uso principale di questa funzione è per la redirezione dell'input e
1006 dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec};
1007 diventa così possibile associare un file (o una pipe) allo standard input o
1008 allo standard output (torneremo sull'argomento in sez.~\ref{sec:ipc_pipe_use},
1009 quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
1010 il file che si vuole sostituire, cosicché il suo file descriptor possa esser
1011 restituito alla chiamata di \func{dup}, come primo file descriptor
1014 Dato che questa è l'operazione più comune, è prevista una diversa versione
1015 della funzione, \funcd{dup2}, che permette di specificare esplicitamente
1016 qual è il valore di file descriptor che si vuole avere come duplicato; il suo
1018 \begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
1020 Rende \param{newfd} una copia del file descriptor \param{oldfd}.
1022 \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
1023 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1025 \item[\errcode{EBADF}] \param{oldfd} non è un file aperto o \param{newfd} ha
1026 un valore fuori dall'intervallo consentito per i file descriptor.
1027 \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
1031 \noindent e qualora il file descriptor \param{newfd} sia già aperto (come
1032 avviene ad esempio nel caso della duplicazione di uno dei file standard) esso
1033 sarà prima chiuso e poi duplicato (così che il file duplicato sarà connesso
1034 allo stesso valore per il file descriptor).
1036 La duplicazione dei file descriptor può essere effettuata anche usando la
1037 funzione di controllo dei file \func{fcntl} (che esamineremo in
1038 sez.~\ref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}. L'operazione ha
1039 la sintassi \code{fcntl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
1040 \param{newfd} diventa equivalente a \func{dup}.
1042 La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i
1043 diversi codici di errore.} è che \func{dup2} chiude il file descriptor
1044 \param{newfd} se questo è già aperto, garantendo che la duplicazione sia
1045 effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
1046 file descriptor libero di valore uguale o maggiore di \param{newfd} (e se
1047 \param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
1050 \subsection{La funzione \func{fcntl}}
1051 \label{sec:file_fcntl}
1053 Oltre alle operazioni base esaminate in sez.~\ref{sec:file_base_func} esistono
1054 tutta una serie di operazioni ausiliarie che è possibile eseguire su un file
1055 descriptor, che non riguardano la normale lettura e scrittura di dati, ma la
1056 gestione sia delle loro proprietà, che di tutta una serie di ulteriori
1057 funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
1058 gestiscono con questa funzione varie modalità di I/O asincrono (vedi
1059 sez.~\ref{sec:file_asyncronous_operation}) e il \textit{file locking}
1060 \index{file!locking} (vedi sez.~\ref{sec:file_locking}).}
1062 Per queste operazioni di manipolazione e di controllo delle varie proprietà e
1063 caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl},
1068 \funcdecl{int fcntl(int fd, int cmd)}
1069 \funcdecl{int fcntl(int fd, int cmd, long arg)}
1070 \funcdecl{int fcntl(int fd, int cmd, struct flock * lock)}
1071 Esegue una delle possibili operazioni specificate da \param{cmd}
1072 sul file \param{fd}.
1074 \bodydesc{La funzione ha valori di ritorno diversi a seconda
1075 dell'operazione. In caso di errore il valore di ritorno è sempre $-1$ ed
1076 il codice dell'errore è restituito nella variabile \var{errno}; i codici
1077 possibili dipendono dal tipo di operazione, l'unico valido in generale è:
1079 \item[\errcode{EBADF}] \param{fd} non è un file aperto.
1084 Il primo argomento della funzione è sempre il numero di file descriptor
1085 \var{fd} su cui si vuole operare. Il comportamento di questa funzione, il
1086 numero e il tipo degli argomenti, il valore di ritorno e gli eventuali errori
1087 sono determinati dal valore dell'argomento \param{cmd} che in sostanza
1088 corrisponde all'esecuzione di un determinato \textsl{comando}; in
1089 sez.~\ref{sec:file_dup} abbiamo incontrato un esempio dell'uso di \func{fcntl}
1090 per la duplicazione dei file descriptor, una lista di tutti i possibili valori
1091 per \var{cmd} è riportata di seguito:
1092 \begin{basedescript}{\desclabelwidth{2.0cm}}
1093 \item[\const{F\_DUPFD}] trova il primo file descriptor disponibile di valore
1094 maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. Ritorna il
1095 nuovo file descriptor in caso di successo e $-1$ in caso di errore. Gli
1096 errori possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore
1097 del massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il
1098 massimo numero di descrittori consentito.
1099 \item[\const{F\_SETFD}] imposta il valore del \textit{file descriptor flag} al
1100 valore specificato con \param{arg}. Al momento l'unico bit usato è quello di
1101 \textit{close-on-exec}\itindex{close-on-exec}, identificato dalla costante
1102 \const{FD\_CLOEXEC}, che serve a richiedere che il file venga chiuso nella
1103 esecuzione di una \func{exec} (vedi sez.~\ref{sec:proc_exec}). Ritorna un
1104 valore nullo in caso di successo e $-1$ in caso di errore.
1105 \item[\const{F\_GETFD}] ritorna il valore del \textit{file descriptor flag} di
1106 \param{fd} o $-1$ in caso di errore; se \const{FD\_CLOEXEC} è impostato i
1107 file descriptor aperti vengono chiusi attraverso una \func{exec} altrimenti
1108 (il comportamento predefinito) restano aperti.
1109 \item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag} in
1110 caso di successo o $-1$ in caso di errore; permette cioè di rileggere quei
1111 bit impostati da \func{open} all'apertura del file che vengono memorizzati
1112 (quelli riportati nella prima e terza sezione di
1113 tab.~\ref{tab:file_open_flags}).
1114 \item[\const{F\_SETFL}] imposta il \textit{file status flag} al valore
1115 specificato da \param{arg}, ritorna un valore nullo in caso di successo o
1116 $-1$ in caso di errore. Possono essere impostati solo i bit riportati nella
1117 terza sezione di tab.~\ref{tab:file_open_flags}.\footnote{la pagina di
1118 manuale riporta come impostabili solo \const{O\_APPEND},
1119 \const{O\_NONBLOCK} e \const{O\_ASYNC}.}
1120 \item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da
1121 \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato;
1122 ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Questa
1123 funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
1124 \item[\const{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
1125 specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da
1126 qualcun altro ritorna immediatamente restituendo $-1$ e imposta \var{errno} a
1127 \errcode{EACCES} o \errcode{EAGAIN}, in caso di successo ritorna un valore
1128 nullo. Questa funzionalità è trattata in dettaglio in
1129 sez.~\ref{sec:file_posix_lock}.
1130 \item[\const{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
1131 la funzione non ritorna subito ma attende che il blocco sia rilasciato. Se
1132 l'attesa viene interrotta da un segnale la funzione restituisce $-1$ e
1133 imposta \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore
1134 nullo. Questa funzionalità è trattata in dettaglio in
1135 sez.~\ref{sec:file_posix_lock}.
1136 \item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o
1137 l'identificatore del \itindex{process~group} \textit{process
1138 group}\footnote{i \itindex{process~group} \textit{process group} sono
1139 (vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel
1140 controllo di sessione; a ciascuno di essi è associato un identificatore
1141 (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione
1142 dei segnali \const{SIGIO} e \const{SIGURG} per gli eventi associati al file
1143 descriptor \param{fd}. Nel caso di un \textit{process group} viene
1144 restituito un valore negativo il cui valore assoluto corrisponde
1145 all'identificatore del \itindex{process~group}\textit{process group}. In
1146 caso di errore viene restituito $-1$.
1147 \item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
1148 l'identificatore del processo o del \itindex{process~group} \textit{process
1149 group} che riceverà i segnali \const{SIGIO} e \const{SIGURG} per gli
1150 eventi associati al file descriptor \param{fd}, ritorna un valore nullo in
1151 caso di successo o $-1$ in caso di errore. Come per \const{F\_GETOWN}, per
1152 impostare un \itindex{process~group} \textit{process group} si deve usare
1153 per \param{arg} un valore negativo, il cui valore assoluto corrisponde
1154 all'identificatore del \itindex{process~group} \textit{process group}.
1155 \item[\const{F\_GETSIG}] restituisce il valore del segnale inviato quando ci
1156 sono dati disponibili in ingresso su un file descriptor aperto ed impostato
1157 per l'I/O asincrono (si veda sez.~\ref{sec:file_asyncronous_io}). Il valore 0
1158 indica il valore predefinito (che è \const{SIGIO}), un valore diverso da
1159 zero indica il segnale richiesto, (che può essere anche lo stesso
1160 \const{SIGIO}). In caso di errore ritorna $-1$.
1161 \item[\const{F\_SETSIG}] imposta il segnale da inviare quando diventa
1162 possibile effettuare I/O sul file descriptor in caso di I/O asincrono,
1163 ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Il
1164 valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro
1165 valore diverso da zero (compreso lo stesso \const{SIGIO}) specifica il
1166 segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è
1167 installato il gestore del segnale come \var{sa\_sigaction} usando
1168 \const{SA\_SIGINFO}, (vedi sez.~\ref{sec:sig_sigaction}), di rendere
1169 disponibili al gestore informazioni ulteriori riguardo il file che ha
1170 generato il segnale attraverso i valori restituiti in \struct{siginfo\_t}
1171 (come vedremo in sez.~\ref{sec:file_asyncronous_io}).\footnote{i due comandi
1172 \const{F\_SETSIG} e \const{F\_GETSIG} sono una estensione specifica di
1174 \item[\const{F\_SETLEASE}] imposta o rimuove un \index{file!lease}
1175 \textit{file lease}\footnote{questa è una nuova funzionalità, specifica di
1176 Linux, e presente solo a partire dai kernel della serie 2.4.x, in cui il
1177 processo che detiene un \textit{lease} su un file riceve una notifica
1178 qualora un altro processo cerca di eseguire una \func{open} o una
1179 \func{truncate} su di esso.} sul file descriptor \var{fd} a seconda del
1180 valore del terzo argomento, che in questo caso è un \ctyp{int}, ritorna un
1181 valore nullo in caso di successo o $-1$ in caso di errore. Questa
1182 funzionalità avanzata è trattata in dettaglio in
1183 sez.~\ref{sec:file_asyncronous_lease}.
1184 \item[\const{F\_GETLEASE}] restituisce il tipo di \textit{file lease}
1185 \index{file!lease} che il processo detiene nei confronti del file descriptor
1186 \var{fd} o $-1$ in caso di errore. Con questo comando il terzo argomento può
1187 essere omesso. Questa funzionalità avanzata è trattata in dettaglio in
1188 sez.~\ref{sec:file_asyncronous_lease}.
1189 \item[\const{F\_NOTIFY}] attiva un meccanismo di notifica per cui viene
1190 riportata al processo chiamante, tramite il segnale \const{SIGIO} (o altro
1191 segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
1192 direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file
1193 in essa contenuti; ritorna un valore nullo in caso di successo o $-1$ in caso
1194 di errore. Questa funzionalità avanzata, disponibile dai kernel della serie
1195 2.4.x, è trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
1198 La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
1199 poter essere affrontate in tutti i loro aspetti a questo punto; saranno
1200 pertanto riprese più avanti quando affronteremo le problematiche ad esse
1201 relative. In particolare le tematiche relative all'I/O asincrono e ai vari
1202 meccanismi di notifica saranno trattate in maniera esaustiva in
1203 sez.~\ref{sec:file_asyncronous_access} mentre quelle relative al \textit{file
1204 locking}\index{file!locking} saranno esaminate in
1205 sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
1206 trattato in sez.~\ref{sec:sock_ctrl_func}.
1208 Si tenga presente infine che quando si usa la funzione per determinare le
1209 modalità di accesso con cui è stato aperto il file (attraverso l'uso del
1210 comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
1211 \textit{file status flag} che si è ottenuto. Infatti la definizione corrente
1212 di quest'ultimo non assegna bit separati alle tre diverse modalità
1213 \const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
1214 queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
1215 motivo il valore della modalità di accesso corrente si ottiene eseguendo un
1216 AND binario del valore di ritorno di \func{fcntl} con la maschera
1217 \const{O\_ACCMODE} (anch'essa definita in \file{fcntl.h}), che estrae i bit di
1218 accesso dal \textit{file status flag}.
1222 \subsection{La funzione \func{ioctl}}
1223 \label{sec:file_ioctl}
1225 Benché il concetto di \textit{everything is a file} si sia dimostrato molto
1226 valido anche per l'interazione con i dispositivi più vari, fornendo una
1227 interfaccia che permette di interagire con essi tramite le stesse funzioni
1228 usate per i normali file di dati, esisteranno sempre caratteristiche
1229 peculiari, specifiche dell'hardware e della funzionalità che ciascun
1230 dispositivo può provvedere, che non possono venire comprese in questa
1231 interfaccia astratta (un caso tipico è l'impostazione della velocità di una
1232 porta seriale, o le dimensioni di un framebuffer).
1234 Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
1235 di una funzione apposita, \funcd{ioctl}, con cui poter compiere le operazioni
1236 specifiche di ogni dispositivo particolare, usando come riferimento il solito
1237 file descriptor. Il prototipo di questa funzione è:
1238 \begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
1239 Manipola il dispositivo sottostante, usando l'argomento \param{request} per
1240 specificare l'operazione richiesta ed il terzo argomento (usualmente di tipo
1241 \param{char * argp} o \param{int argp}) per il trasferimento
1242 dell'informazione necessaria.
1244 \bodydesc{La funzione nella maggior parte dei casi ritorna 0, alcune
1245 operazioni usano però il valore di ritorno per restituire informazioni. In
1246 caso di errore viene sempre restituito $-1$ ed \var{errno} assumerà uno dei
1249 \item[\errcode{ENOTTY}] il file \param{fd} non è associato con un
1250 dispositivo, o la richiesta non è applicabile all'oggetto a cui fa
1251 riferimento \param{fd}.
1252 \item[\errcode{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
1255 ed inoltre \errval{EBADF} e \errval{EFAULT}.}
1258 La funzione serve in sostanza per fare tutte quelle operazioni che non si
1259 adattano al design dell'architettura dei file e che non è possibile effettuare
1260 con le funzioni esaminate finora. Esse vengono selezionate attraverso il
1261 valore di \param{request} e gli eventuali risultati possono essere restituiti
1262 sia attraverso il valore di ritorno che attraverso il terzo argomento
1263 \param{argp}. Sono esempi delle operazioni gestite con una \func{ioctl}:
1265 \item il cambiamento dei font di un terminale.
1266 \item l'esecuzione di una traccia audio di un CDROM.
1267 \item i comandi di avanti veloce e riavvolgimento di un nastro.
1268 \item il comando di espulsione di un dispositivo rimovibile.
1269 \item l'impostazione della velocità trasmissione di una linea seriale.
1270 \item l'impostazione della frequenza e della durata dei suoni emessi dallo
1274 In generale ogni dispositivo ha un suo insieme di possibili diverse operazioni
1275 effettuabili attraverso \func{ioctl}, che sono definite nell'header file
1276 \file{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui fanno
1277 riferimento. Infatti anche se in genere i valori di \param{request} sono
1278 opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
1279 un apposito \textit{magic number} per distinguere ciascun dispositivo nella
1280 definizione delle macro da usare per \param{request}, in modo da essere
1281 sicuri che essi siano sempre diversi, ed il loro uso per dispositivi diversi
1282 causi al più un errore. Si veda il capitolo quinto di \cite{LinDevDri} per
1283 una trattazione dettagliata dell'argomento.} così che la richiesta di
1284 operazioni relative ad altri dispositivi usualmente provoca il ritorno della
1285 funzione con una condizione di errore, in alcuni casi, relativi a valori
1286 assegnati prima che questa differenziazione diventasse pratica corrente, si
1287 potrebbero usare valori validi anche per il dispositivo corrente, con effetti
1288 imprevedibili o indesiderati.
1290 Data la assoluta specificità della funzione, il cui comportamento varia da
1291 dispositivo a dispositivo, non è possibile fare altro che dare una descrizione
1292 sommaria delle sue caratteristiche; torneremo ad esaminare in
1293 seguito\footnote{per l'uso con i socket si veda
1294 sez.~\ref{sec:sock_ctrl_func}.} quelle relative ad alcuni casi specifici
1295 (ad esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
1296 quasi tutte le implementazioni di Unix), qui riportiamo solo i valori di
1297 alcuni comandi che sono definiti per ogni file:
1298 \begin{basedescript}{\desclabelwidth{2.0cm}}
1299 \item[\const{FIOCLEX}] Imposta il flag di
1300 \textit{close-on-exec}\itindex{close-on-exec}.
1301 \item[\const{FIONCLEX}] Cancella il flag di
1302 \textit{close-on-exec}\itindex{close-on-exec}.
1303 \item[\const{FIOASYNC}] Abilita l'I/O asincrono.
1304 \item[\const{FIONBIO}] Abilita l'I/O in modalità non bloccante.
1306 relativi ad operazioni comunque eseguibili anche attraverso \func{fcntl}.
1310 % TODO estendere la lista delle ioctl
1313 %%% Local Variables:
1315 %%% TeX-master: "gapil"
1318 % LocalWords: descriptor system call cap like kernel sez l'inode inode VFS tab
1319 % LocalWords: process table struct files flags pos all'inode dentry fig shell
1320 % LocalWords: error POSIX STDIN FILENO STDOUT STDERR unistd read write lseek
1321 % LocalWords: close pathname sys fcntl int const char errno EEXIST CREAT EXCL
1322 % LocalWords: EISDIR ENOTDIR ENXIO NOBLOCK WRONLY fifo ENODEV ETXTBSY ELOOP of
1323 % LocalWords: NOFOLLOW EACCES ENAMETOOLONG ENOENT EROFS EFAULT ENOSPC ENOMEM
1324 % LocalWords: EMFILE ENFILE NFS lock race condition Denial Service DoS RDONLY
1325 % LocalWords: glibc RDWR NONBLOCK NOCTTY SHLOCK shared BSD EXLOCK TRUNC device
1326 % LocalWords: opendir LARGEFILE APPEND append NDELAY ASYNC l'I SIGIO SYNC SVr
1327 % LocalWords: DSYNC RSYNC filesystem DIRECT caching SGI IRIX dell'I FreeBSD fd
1328 % LocalWords: fork exec umask SOURCE creat filedes EBADF EINTR EIO locking off
1329 % LocalWords: behind sync flush shutdown whence ESPIPE socket EINVAL INCR XTND
1330 % LocalWords: SEEK CUR EPIPE ssize void buf size count EAGAIN EWOULDBLOCK log
1331 % LocalWords: Specification pwrite pread EFBIG SIGPIPE nell'inode dall'inode
1332 % LocalWords: CLOEXEC stat fsync cache update l'update bdflush Documentation
1333 % LocalWords: fdatasync fstat ext dup oldfd newfd DUPFD cmd long arg flock pid
1334 % LocalWords: SETFD GETFD GETFL SETFL GETLK SETLK SETLKW GETOWN group SIGURG
1335 % LocalWords: SETOWN GETSIG SETSIG sigaction SIGINFO siginfo SETLEASE lease is
1336 % LocalWords: truncate GETLEASE NOTIFY all'I AND ACCMODE ioctl everything argp
1337 % LocalWords: framebuffer request ENOTTY CDROM nell'header magic number
1338 % LocalWords: FIOCLEX FIONCLEX FIOASYNC FIONBIO NOATIME