1 \chapter{I file: l'interfaccia standard Unix}
2 \label{cha:file_unix_interface}
4 Esamineremo in questo capitolo la prima delle due interfacce di programmazione
5 per i file, quella dei \textit{file descriptor}, nativa di Unix. Questa è
6 l'interfaccia di basso livello provvista direttamente dalle system call, che
7 non prevede funzionalità evolute come la bufferizzazione o funzioni di lettura
8 o scrittura formattata, e sulla quale è costruita anche l'interfaccia definita
9 dallo standard ANSI C che affronteremo al \capref{cha:files_std_interface}.
13 \section{L'architettura di base}
14 \label{sec:file_base_arch}
16 In questa sezione faremo una breve introduzione sull'architettura su cui è
17 basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con
18 differenze nella realizzazione pratica, resta sostanzialmente la stessa in
19 tutte le implementazione di un sistema unix-like.
22 \subsection{L'architettura dei \textit{file descriptor}}
25 Per poter accedere al contenuto di un file occorre creare un canale di
26 comunicazione con il kernel che renda possibile operare su di esso (si ricordi
27 quanto visto in \secref{sec:file_vfs_work}). Questo si fa aprendo il file con
28 la funzione \func{open} che provvederà a localizzare l'inode del file e
29 inizializzare i puntatori che rendono disponibili le funzioni che il VFS mette
30 a disposizione (riportate in \tabref{tab:file_file_operations}). Una volta
31 terminate le operazioni, il file dovrà essere chiuso, e questo chiuderà il
32 canale di comunicazione impedendo ogni ulteriore operazione.
34 All'interno di ogni processo i file aperti sono identificati da un intero non
35 negativo, chiamato appunto \textit{file descriptor}. Quando un file viene
36 aperto la funzione \func{open} restituisce questo numero, tutte le ulteriori
37 operazioni saranno compiute specificando questo stesso valore come argomento
38 alle varie funzioni dell'interfaccia.
40 Per capire come funziona il meccanismo occorre spiegare a grandi linee come è
41 che il kernel gestisce l'interazione fra processi e file. Il kernel mantiene
42 sempre un elenco dei processi attivi nella cosiddetta \textit{process table}
43 ed un elenco dei file aperti nella \textit{file table}.
45 La \textit{process table} è una tabella che contiene una voce per ciascun
46 processo attivo nel sistema. In Linux ciascuna voce è costituita da una
47 struttura di tipo \var{task\_struct} nella quale sono raccolte tutte le
48 informazioni relative al processo; fra queste informazioni c'è anche il
49 puntatore ad una ulteriore struttura di tipo \var{files\_struct}, in cui sono
50 contenute le informazioni relative ai file che il processo ha aperto, ed in
53 \item i flag relativi ai file descriptor.
54 \item il numero di file aperti.
55 \item una tabella che contiene un puntatore alla relativa voce nella
56 \textit{file table} per ogni file aperto.
58 il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
61 La \textit{file table} è una tabella che contiene una voce per ciascun file
62 che è stato aperto nel sistema. In Linux è costituita da strutture di tipo
63 \var{file}; in ciascuna di esse sono tenute varie informazioni relative al
66 \item lo stato del file (nel campo \var{f\_flags}).
67 \item il valore della posizione corrente (l'\textit{offset}) nel file (nel
69 \item un puntatore all'inode\footnote{nel kernel 2.4.x si è in realtà passati
70 ad un puntatore ad una struttura \var{dentry} che punta a sua volta
71 all'inode passando per la nuova struttura del VFS.} del file.
72 %\item un puntatore alla tabella delle funzioni \footnote{la struttura
73 % \var{f\_op} descritta in \secref{sec:file_vfs_work}} che si possono usare
77 In \figref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
78 questa architettura, ed in cui si sono evidenziate le interrelazioni fra le
79 varie strutture di dati sulla quale essa è basata.
82 \includegraphics[width=13cm]{img/procfile}
83 \caption{Schema della architettura dell'accesso ai file attraverso
84 l'interfaccia dei \textit{file descriptor}.}
85 \label{fig:file_proc_file}
87 Ritorneremo su questo schema più volte, dato che esso è fondamentale per
88 capire i dettagli del funzionamento dell'interfaccia dei \textit{file
92 \subsection{I file standard}
93 \label{sec:file_std_descr}
95 Come accennato i \textit{file descriptor} non sono altro che un indice nella
96 tabella dei file aperti di ciascun processo; per questo motivo essi vengono
97 assegnati in successione tutte le volte che si apre un nuovo file (se non ne è
98 stato chiuso nessuno in precedenza).
100 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
101 processo viene lanciato con almeno tre file aperti. Questi, per quanto appena
102 detto, avranno come \textit{file descriptor} i valori 0, 1 e 2. Benché questa
103 sia soltanto una convenzione, essa è seguita dalla gran parte delle
104 applicazioni, e non aderirvi potrebbe portare a gravi problemi di
107 Il primo file è sempre associato a quello che viene chiamato \textit{standard
108 input}. È cioè il file da cui il processo si aspetta di ricevere i dati in
109 ingresso (nel caso della shell, è associato all'ingresso dal terminale, e
110 quindi alla lettura della tastiera). Il secondo file è il cosiddetto
111 \textit{standard output}, cioè il file su cui ci si aspetta debbano essere
112 inviati i dati in uscita (sempre nel caso della shell, è associato all'uscita
113 del terminale, e quindi alla scrittura sullo schermo). Il terzo è lo
114 \textit{standard error}, su cui viene inviato l'output relativo agli errori,
115 ed è anch'esso associato all'uscita del termininale. Lo standard POSIX.1
116 provvede tre costanti simboliche, definite nell'header \file{unistd.h}, al
117 posto di questi valori numerici:
121 \begin{tabular}[c]{|l|l|}
123 \textbf{Costante} & \textbf{Significato} \\
126 \macro{STDIN\_FILENO} & \textit{file descriptor} dello \textit{standard
128 \macro{STDOUT\_FILENO} & \textit{file descriptor} dello \textit{standard
130 \macro{STDERR\_FILENO} & \textit{file descriptor} dello \textit{standard
134 \caption{Costanti definite in \file{unistd.h} per i file standard aperti
135 alla creazione di ogni processo.}
136 \label{tab:file_std_files}
139 In \curfig\ si è utilizzata questa situazione come esempio, facendo
140 riferimento ad un programma in cui lo \textit{standard input} è associato ad
141 un file mentre lo \textit{standard output} e lo \textit{standard error} sono
142 entrambi associati ad un altro file (e quindi utilizzano lo stesso inode).
144 Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
145 numero di file aperti era anche soggetto ad un limite massimo dato dalle
146 dimensioni del vettore di puntatori con cui era realizzata la tabella dei file
147 descriptor dentro \var{file\_struct}; questo limite intrinseco nei kernel più
148 recenti non sussiste più, dato che si è passati da un vettore ad una lista, ma
149 restano i limiti imposti dall'amministratore (vedi \secref{sec:sys_limits}).
153 \section{Le funzioni base}
154 \label{sec:file_base_func}
156 L'interfaccia standard Unix per l'input/output sui file è basata su cinque
157 funzioni fondamentali: \func{open}, \func{read}, \func{write}, \func{lseek} e
158 \func{close}, usate rispettivamente per aprire, leggere, scrivere, spostarsi e
161 La gran parte delle operazioni sui file si effettua attraverso queste cinque
162 funzioni, esse vengono chiamate anche funzioni di I/O non bufferizzato dato
163 che effettuano le operazioni di lettura e scrittura usando direttamente le
164 system call del kernel.
167 \subsection{La funzione \func{open}}
168 \label{sec:file_open}
170 La funzione \func{open} è la funzione fondamentale per accedere ai file, ed è
171 quella che crea l'associazione fra un pathname ed un file descriptor, il suo
174 \headdecl{sys/types.h}
175 \headdecl{sys/stat.h}
177 \funcdecl{int open(const char *pathname, int flags)}
178 \funcdecl{int open(const char *pathname, int flags, mode\_t mode)}
179 Apre il file indicato da \var{pathname} nella modalità indicata da
180 \var{flags}, e, nel caso il file sia creato, con gli eventuali permessi
181 specificati da \var{mode}.
183 \bodydesc{La funzione ritorna il file descriptor in caso di successo e -1 in
184 caso di errore. In questo caso la variabile \var{errno} viene settata ad
187 \item[\macro{EEXIST}] \var{pathname} esiste e si è specificato
188 \macro{O\_CREAT} e \macro{O\_EXCL}.
189 \item[\macro{EISDIR}] \var{pathname} indica una directory e si è tentato
190 l'accesso in scrittura.
191 \item[\macro{ENOTDIR}] si è specificato \macro{O\_DIRECTORY} e \var{pathname}
193 \item[\macro{ENXIO}] si sono settati \macro{O\_NOBLOCK} o \macro{O\_WRONLY}
194 ed il file è una fifo che non viene letta da nessun processo o
195 \var{pathname} è un file di dispositivo ma il dispositivo è assente.
196 \item[\macro{ENODEV}] \var{pathname} si riferisce a un file di dispositivo
198 \item[\macro{ETXTBSY}] si è cercato di accedere in scrittura all'immagine di
199 un programma in esecuzione.
200 \item[\macro{ELOOP}] si sono incontrati troppi link simbolici nel risolvere
201 pathname o si è indicato \macro{O\_NOFOLLOW} e \var{pathname} è un link
204 ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOENT},
205 \macro{EROFS}, \macro{EFAULT}, \macro{ENOSPC}, \macro{ENOMEM},
206 \macro{EMFILE} e \macro{ENFILE}.}
209 La funzione apre il file, usando il primo file descriptor libero, e crea
210 l'opportuna voce (cioè la struttura \var{file}) nella file table. Viene usato
211 sempre il file descriptor con il valore più basso.
216 \begin{tabular}[c]{|l|p{12cm}|}
218 \textbf{Flag} & \textbf{Descrizione} \\
220 \hline % modalità di accesso al file
221 \macro{O\_RDONLY} & apre il file in sola lettura. \\
222 \macro{O\_WRONLY} & apre il file in sola scrittura. \\
223 \macro{O\_RDWR} & apre il file lettura/scrittura. \\
224 \hline % modalità di apertura del file
226 \macro{O\_CREAT} & se il file non esiste verrà creato, con le regole di
227 titolarità del file viste in \secref{sec:file_ownership}. Il parametro
228 \var{mode} deve essere specificato. \\
229 \macro{O\_EXCL} & usato in congiunzione con \macro{O\_CREAT} fa sì che
230 l'esistenza del file diventi un errore\protect\footnotemark\ che fa fallire
231 \func{open} con \macro{EEXIST}. \\
232 \macro{O\_NONBLOCK} & apre il file in modalità non bloccante. Questo
233 valore specifica anche una modalità di operazione (vedi sotto), e
234 comporta che \func{open} ritorni immediatamente (torneremo su
235 questo in \secref{sec:file_noblocking}). \\
236 \macro{O\_NOCTTY} & se \var{pathname} si riferisce ad un device di
237 terminale, questo non diventerà il terminale di controllo, anche se il
238 processo non ne ha ancora uno (si veda \secref{sec:sess_xxx}). \\
239 \macro{O\_SHLOCK} & opzione di BSD, acquisisce uno shared lock (vedi
240 \secref{sec:file_locking}) sul file. Non è disponibile in Linux. \\
241 \macro{O\_EXLOCK} & opzione di BSD, acquisisce uno lock esclusivo (vedi
242 \secref{sec:file_locking}) sul file. Non è disponibile in Linux. \\
243 \macro{O\_TRUNC} & se il file esiste ed è un file di dati e la modalità di
244 apertura consente la scrittura, allora la sua lunghezza verrà troncata a
245 zero. Se il file è un terminale o una fifo il flag verrà ignorato, negli
246 altri casi il comportamento non è specificato. \\
247 \macro{O\_NOFOLLOW} & se \var{pathname} è un link simbolico la chiamata
248 fallisce. Questa è un'estensione BSD aggiunta in Linux dal kernel 2.1.126.
249 Nelle versioni precedenti i link simbolici sono sempre seguiti, e questa
250 opzione è ignorata. \\
251 \macro{O\_DIRECTORY} & se \var{pathname} non è una directory la chiamata
252 fallisce. Questo flag è specifico di Linux ed è stato introdotto con il
253 kernel 2.1.126 per evitare dei DoS\protect\footnotemark\ quando
254 \func{opendir} viene chiamata su una
255 fifo o su un device di unità a nastri, non deve essere utilizzato al di
256 fuori dell'implementazione di \func{opendir}. \\
257 \macro{O\_LARGEFILE} & nel caso di sistemi a 32 bit che supportano file di
258 grandi dimensioni consente di aprire file le cui dimensioni non possono
259 essere rappresentate da numeri a 31 bit. \\
261 \hline % modalità di operazione col file
262 \macro{O\_APPEND} & il file viene aperto in append mode. Prima di ciascuna
263 scrittura la posizione corrente viene sempre settata alla fine del
264 file. Può causare corruzione del file con NFS se più di un processo scrive
265 allo stesso tempo.\footnotemark\\
266 \macro{O\_NONBLOCK} & il file viene aperto in modalità non bloccante per
267 le operazioni di I/O: questo significa il fallimento di una \func{read} in
268 assenza di dati da leggere e quello di una \func{write} in caso di
269 impossibilità di scrivere immediatamente. L'opzione è effettiva solo per
270 le fifo e per alcuni file di dispositivo. \\
271 \macro{O\_NDELAY} & in Linux\footnotemark\ è sinonimo di
272 \macro{O\_NONBLOCK}.\\
273 \macro{O\_ASYNC} & apre il file per l'input/output in modalità
274 asincrona. Quando è settato viene generato un segnale di \macro{SIGIO}
275 tutte le volte che è disponibile dell'input sul file. \\
276 \macro{O\_SYNC} & apre il file per l'input/output sincrono, ogni
277 \func{write} bloccherà fino al completamento della scrittura di tutti dati
278 sul sull'hardware sottostante.\\
279 \macro{O\_FSYNC} & sinonimo di \macro{O\_SYNC}. \\
280 \macro{O\_NOATIME} & blocca l'aggiornamento dei tempi dei di accesso dei
281 file (vedi \secref{sec:file_file_times}). In Linux questa opzione non è
282 disponibile per il singolo file ma come opzione per il filesystem in fase
286 \caption{Valori e significato dei vari bit del \textit{file status flag}.}
287 \label{tab:file_open_flags}
290 \footnotetext[2]{la man page di \func{open} segnala che questa opzione è
291 difettosa su NFS, e che i programmi che la usano per stabilire un file di
292 lock possono incorrere in una race condition. Si consiglia come alternativa
293 di usare un file con un nome univoco e la funzione \func{link} per
294 verificarne l'esistenza.}
296 \footnotetext[3]{Denial of Service, si chiamano così attacchi miranti ad
297 impedire un servizio causando una qualche forma di carico eccessivo per il
298 sistema, che resta bloccato nelle risposte all'attacco.}
300 \footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
301 il kernel deve simularla, ma questo comporta la possibilità di una race
302 condition, vedi \secref{sec:file_atomic}.}
304 \footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
305 una \func{read} con un valore nullo e non con un errore, questo introduce
306 un'ambiguità, dato che come vedremo in \secref{sec:file_read} il ritorno di
307 zero da parte di \func{read} ha il significato di una end-of-file.}
309 Questa caratteristica permette di prevedere qual'è il valore del file
310 descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
311 alcune applicazioni per sostituire i file corrispondenti ai file standard
312 visti in \secref{sec:file_std_descr}: se ad esempio si chiude lo standard
313 input e si apre subito dopo un nuovo file questo diventerà il nuovo standard
314 input (avrà cioè il file descriptor 0).
316 Il nuovo file descriptor non è condiviso con nessun altro processo, (torneremo
317 sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
318 \secref{sec:file_sharing}). Il nuovo file descriptor è settato di default per
319 restare aperto attraverso una \func{exec} (come accennato in
320 \secref{sec:proc_exec}) e l'offset è settato all'inizio del file.
322 L'argomento \param{mode} specifica i permessi con cui il file viene
323 eventualmente creato; i valori possibili sono gli stessi già visti in
324 \secref{sec:file_perm_overview} e possono essere specificati come OR binario
325 delle costanti descritte in \tabref{tab:file_bit_perm}. Questi permessi sono
326 filtrati dal valore di \var{umask} (vedi \secref{sec:file_umask}) per il
329 La funzione prevede diverse opzioni, che vengono specificate usando vari bit
330 dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire
331 il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
332 campo \var{f\_flags} della struttura \var{file} (al solito si veda lo schema
333 di \curfig). Essi sono divisi in tre categorie principali:
335 \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
336 si accederà al file: i valori possibili sono lettura, scrittura o
337 lettura/scrittura. Uno di questi bit deve essere sempre specificato quando
338 si apre un file. Vengono settati alla chiamata da \func{open}, e possono
339 essere riletti con una \func{fcntl} (fanno parte del \textit{file status
340 flag}), ma non possono essere modificati.
341 \item \textsl{i bit delle modalità di apertura}: permettono di specificare
342 alcune delle caratteristiche del comportamento di \func{open} quando viene
343 eseguita. Hanno effetto solo al momento della chiamata della funzione e non
344 sono memorizzati né possono essere riletti.
345 \item \textsl{i bit delle modalità di operazione}: permettono di specificare
346 alcune caratteristiche del comportamento delle future operazioni sul file
347 (come la \func{read} o la \func{write}). Anch'essi fanno parte del
348 \textit{file status flag}. Il loro valore è settato alla chiamata di
349 \func{open}, ma possono essere riletti e modificati (insieme alle
350 caratteristiche operative che controllano) con una \func{fcntl}.
353 In \tabref{tab:file_open_flags} si sono riportate, ordinate e divise fra loro
354 secondo le tre modalità appena elencate, le costanti mnemoniche associate a
355 ciascuno di questi bit. Dette costanti possono essere combinate fra di loro
356 con un OR aritmetico per costruire il valore (in forma di maschera binaria)
357 dell'argomento \param{flags} da passare alla \func{open} per specificarne il
358 comportamento. I due flag \macro{O\_NOFOLLOW} e \macro{O\_DIRECTORY} sono
359 estensioni specifiche di Linux, e deve essere usata definita la macro
360 \macro{\_GNU\_SOURCE} per poterli usare.
362 Nelle prime versioni di Unix i valori di \param{flag} specificabili per
363 \func{open} erano solo quelli relativi alle modalità di accesso del file. Per
364 questo motivo per creare un nuovo file c'era una system call apposita,
365 \func{creat}, il cui prototipo è:
366 \begin{prototype}{fcntl.h}
367 {int creat(const char *pathname, mode\_t mode)}
368 Crea un nuovo file vuoto, con i permessi specificati da \var{mode}. É del
369 tutto equivalente a \code{open(filedes, O\_CREAT|O\_WRONLY|O\_TRUNC, mode)}.
371 \noindent adesso questa funzione resta solo per compatibilità con i vecchi
375 \subsection{La funzione \func{close}}
376 \label{sec:file_close}
378 La funzione \func{close} permette di chiudere un file, in questo modo il file
379 descriptor ritorna disponibile; il suo prototipo è:
380 \begin{prototype}{unistd.h}{int close(int fd)}
381 Chiude il descrittore \var{fd}.
383 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
384 ed in questo caso \var{errno} è settata ai valori:
386 \item[\macro{EBADF}] \var{fd} non è un descrittore valido.
387 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale.
389 ed inoltre \macro{EIO}.}
392 La chiusura di un file rilascia ogni blocco (il \textit{file locking} è
393 trattato in \secref{sec:file_locking}) che il processo poteva avere acquisito
394 su di esso; se \var{fd} è l'ultimo riferimento (di eventuali copie) ad un file
395 aperto, tutte le risorse nella file table vengono rilasciate. Infine se il
396 file descriptor era l'ultimo riferimento ad un file su disco quest'ultimo
399 Si ricordi che quando un processo termina anche tutti i suoi file descriptor
400 vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
401 esplicitamente \func{close}. In genere comunque chiudere un file senza
402 controllarne lo stato di uscita è errore; infatti molti filesystem
403 implementano la tecnica del \textit{write-behind}, per cui una \func{write}
404 può avere successo anche se i dati non sono stati scritti, un eventuale errore
405 di I/O allora può sfuggire, ma verrà riportato alla chiusura del file: per
406 questo motivo non effettuare il controllo può portare ad una perdita di dati
407 inavvertita.\footnote{in Linux questo comportamento è stato osservato con NFS
408 e le quote su disco.}
410 In ogni caso una \func{close} andata a buon fine non garantisce che i dati
411 siano stati effettivamente scritti su disco, perché il kernel può decidere di
412 ottimizzare l'accesso a disco ritardandone la scrittura. L'uso della funzione
413 \func{sync} (vedi \secref{sec:file_sync}) effettua esplicitamente il
414 \emph{flush} dei dati, ma anche in questo caso resta l'incertezza dovuta al
415 comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
416 dell'accesso al disco che ritardano la scrittura dei dati, da cui l'abitudine
417 di ripetere tre volte il comando prima di eseguire lo shutdown).
420 \subsection{La funzione \func{lseek}}
421 \label{sec:file_lseek}
423 Come già accennato in \secref{sec:file_fd} a ciascun file aperto è associata
424 una \textsl{posizione corrente nel file} (il cosiddetto \textit{file offset},
425 mantenuto nel campo \var{f\_pos} di \var{file}) espressa da un numero intero
426 positivo come numero di byte dall'inizio del file. Tutte le operazioni di
427 lettura e scrittura avvengono a partire da questa posizione che viene
428 automaticamente spostata in avanti del numero di byte letti o scritti.
430 In genere (a meno di non avere richiesto la modalità \macro{O\_APPEND}) questa
431 posizione viene settata a zero all'apertura del file. È possibile settarla ad
432 un valore qualsiasi con la funzione \func{lseek}, il cui prototipo è:
434 \headdecl{sys/types.h}
436 \funcdecl{off\_t lseek(int fd, off\_t offset, int whence)}
437 Setta la posizione attuale nel file.
439 \bodydesc{La funzione ritorna valore della posizione corrente in caso di
440 successo e -1 in caso di errore nel qual caso \var{errno} viene settata ad
443 \item[\macro{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
444 \item[\macro{EINVAL}] \param{whence} non è un valore valido.
446 ed inoltre \macro{EBADF}.}
449 La nuova posizione è settata usando il valore specificato da \param{offset},
450 sommato al riferimento dato da \param{whence}; quest'ultimo può assumere i
451 seguenti valori\footnote{per compatibilità con alcune vecchie notazioni
452 questi valori possono essere rimpiazzati rispettivamente con 0, 1 e 2 o con
453 \macro{L\_SET}, \macro{L\_INCR} e \macro{L\_XTND}.}:
454 \begin{basedescript}{\desclabelwidth{2.0cm}}
455 \item[\macro{SEEK\_SET}] si fa riferimento all'inizio del file: il valore di
456 \var{offset} è la nuova posizione.
457 \item[\macro{SEEK\_CUR}] si fa riferimento alla posizione corrente del file:
458 \var{offset} può essere negativo e positivo.
459 \item[\macro{SEEK\_END}] si fa riferimento alla fine del file: il valore di
460 \var{offset} può essere negativo e positivo.
463 Come accennato in \secref{sec:file_file_size} con \func{lseek} è possibile
464 settare la posizione corrente anche al di la della fine del file, e alla
465 successiva scrittura il file sarà esteso. La chiamata non causa nessuna
466 attività di input/output, si limita a modificare la posizione corrente nel
467 kernel (cioè \var{f\_pos} in \var{file}, vedi \figref{fig:file_proc_file}).
469 Dato che la funzione ritorna la nuova posizione, usando il valore zero per
470 \param{offset} si può riottenere la posizione corrente nel file chiamando la
471 funzione con \code{lseek(fd, 0, SEEK\_CUR)}.
473 Si tenga presente inoltre che usare \macro{SEEK\_END} non assicura affatto che
474 successiva scrittura avvenga alla fine del file, infatti se questo è stato
475 aperto anche da un altro processo che vi ha scritto, la fine del file può
476 essersi spostata, ma noi scriveremo alla posizione settata in precedenza.
477 (questa è una potenziale sorgente di \textit{race condition}, vedi
478 \secref{sec:file_atomic}).
480 Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
481 questo caso la funzione ritorna l'errore \macro{EPIPE}. Questo, oltre che per
482 i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che non
483 supportano questa funzione, come ad esempio per le \acr{tty}.\footnote{altri
484 sistemi, usando \macro{SEEK\_SET}, in questo caso ritornano il numero di
485 caratteri che vi sono stati scritti.} Lo standard POSIX però non specifica
486 niente al proposito. Infine alcuni device, ad esempio \file{/dev/null}, non
487 causano un errore ma restituiscono un valore indefinito.
490 \subsection{La funzione \func{read}}
491 \label{sec:file_read}
494 Una volta che un file è stato aperto su possono leggere i dati che contiene
495 utilizzando la funzione \func{read}, il cui prototipo è:
496 \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
498 Cerca di leggere \var{count} byte dal file \var{fd} al buffer \var{buf}.
500 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
501 -1 in caso di errore, nel qual caso \var{errno} viene settata ad uno dei
504 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale prima di
505 aver potuto leggere qualsiasi dato.
506 \item[\macro{EAGAIN}] la funzione non aveva nessun dato da restituire e si
507 era aperto il file in modalità \macro{O\_NONBLOCK}.
509 ed inoltre \macro{EBADF}, \macro{EIO}, \macro{EISDIR}, \macro{EBADF},
510 \macro{EINVAL} e \macro{EFAULT} ed eventuali altri errori dipendenti dalla
511 natura dell'oggetto connesso a \var{fd}.}
514 La funzione tenta di leggere \var{count} byte a partire dalla posizione
515 corrente nel file. Dopo la lettura la posizione sul file è spostata
516 automaticamente in avanti del numero di byte letti. Se \var{count} è zero la
517 funzione restituisce zero senza nessun altro risultato.
519 Si deve sempre tener presente che non è detto che la funzione \func{read}
520 restituisca sempre il numero di byte richiesto, ci sono infatti varie ragioni
521 per cui la funzione può restituire un numero di byte inferiore; questo è un
522 comportamento normale, e non un errore, che bisogna sempre tenere presente.
524 La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
525 di quanto il file ne contenga. In questo caso il file viene letto fino alla
526 sua fine, e la funzione ritorna regolarmente il numero di byte letti
529 Raggiunta la fine del file, alla ripetizione di un'operazione di lettura,
530 otterremmo il ritorno immediato di \func{read} con uno zero. La condizione
531 raggiungimento della fine del file non è un errore, e viene segnalata appunto
532 da un valore di ritorno di \func{read} nullo. Ripetere ulteriormente la
533 lettura non avrebbe nessun effetto se non quello di continuare a ricevere zero
534 come valore di ritorno.
536 Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
537 un numero di byte letti inferiore a quello richiesto, ma questo non è vero
538 quando si legge da un terminale, da una fifo o da una pipe. In tal caso
539 infatti, se non ci sono dati in ingresso, la \func{read} si blocca e ritorna
540 solo quando ne arrivano; se il numero di byte richiesti eccede quelli
541 disponibili la funzione ritorna comunque, ma con un numero di byte inferiore a
544 Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
545 come vedremo in \secref{sec:sock_io_behav}), o per certi dispositivi, come le
546 unità a nastro, che restituiscono un singolo blocco di dati alla volta.
548 In realtà anche le due condizioni segnalate dagli errori \macro{EINTR} e
549 \macro{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è
550 bloccata in attesa di dati in ingresso e viene interrotta da un segnale; in
551 tal caso l'azione da prendere è quella di rieseguire la funzione. Torneremo
552 sull'argomento in \secref{sec:sig_gen_beha}.
554 La seconda si verifica quando il file è in modalità non bloccante e non ci
555 sono dati in ingresso: la funzione allora ritorna immediatamente con un errore
556 \macro{EAGAIN}\footnote{sotto BSD questo per questo errore viene usata la
557 costante \macro{EWOULDBLOCK}, in GNU/Linux questa è sinonima di
558 \macro{EAGAIN}.} che nel caso indica soltanto che occorrerà provare a
562 Nella seconda versione delle \textit{Single Unix
563 Specification}\footnote{questa funzione, e l'analoga \func{pwrite} sono
564 state aggiunte nel kernel 2.1.60, il supporto nelle \acr{glibc}, compresa
565 l'emulazione per i vecchi kernel che non hanno la system call, è stato
566 aggiunto con la versione 2.1.} (quello che viene chiamato normalmente Unix98,
567 vedi \secref{sec:intro_opengroup}) è stata introdotta la definizione di
568 un'altra funzione di lettura, \func{pread}, che diventa accessibile con la
571 #define _XOPEN_SOURCE 500
573 il prototipo di questa funzione è:
574 \begin{prototype}{unistd.h}
575 {ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
577 Cerca di leggere \var{count} byte dal file \var{fd}, a partire dalla posizione
578 \var{offset}, nel buffer \var{buf}.
580 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e -1
581 in caso di errore, nel qual caso \var{errno} viene settata secondo i valori
582 già visti per \func{read} e \func{lseek}.}
585 Questa funzione serve quando si vogliono leggere dati dal file senza
586 modificarne la posizione corrente. È equivalente alla esecuzione di una
587 \func{read} e una \func{lseek}, ma permette di eseguire l'operazione
588 atomicamente. Questo può essere importante quando la posizione sul file viene
589 condivisa da processi diversi (vedi \secref{sec:file_sharing}). Il valore di
590 \var{offset} fa sempre riferimento all'inizio del file.
593 \subsection{La funzione \func{write}}
594 \label{sec:file_write}
596 Una volta che un file è stato aperto su può scrivere su di esso utilizzando la
597 funzione \func{write}, il cui prototipo è:
598 \begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
600 Scrive \var{count} byte dal buffer \var{buf} sul file \var{fd}.
602 \bodydesc{La funzione ritorna il numero di byte scritti in caso di successo
603 e -1 in caso di errore, nel qual caso \var{errno} viene settata ad uno dei
606 \item[\macro{EINVAL}] \var{fd} è connesso ad un oggetto che non consente la
608 \item[\macro{EFBIG}] si è cercato di scrivere oltre la dimensione massima
609 consentita dal filesystem o il limite per le dimensioni dei file del
610 processo o su una posizione oltre il massimo consentito.
611 \item[\macro{EPIPE}] \var{fd} è connesso ad una pipe il cui altro capo è
612 chiuso in lettura; in questo caso viene anche generato il segnale
613 \macro{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
614 funzione ritorna questo errore.
615 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale prima di
616 aver potuto scrivere qualsiasi dato.
617 \item[\macro{EAGAIN}] la funzione non aveva nessun dato da restituire e si
618 era aperto il file in modalità \macro{O\_NONBLOCK}.
620 ed inoltre \macro{EBADF}, \macro{EIO}, \macro{EISDIR}, \macro{EBADF},
621 \macro{ENOSPC}, \macro{EINVAL} e \macro{EFAULT} ed eventuali altri errori
622 dipendenti dalla natura dell'oggetto connesso a \var{fd}.}
625 Come nel caso di \func{read} la funzione tenta di scrivere \var{count} byte a
626 partire dalla posizione corrente nel file e sposta automaticamente la
627 posizione in avanti del numero di byte scritti. Se il file è aperto in
628 modalità \macro{O\_APPEND} i dati vengono sempre scritti alla fine del file.
629 Lo standard POSIX richiede che i dati scritti siano immediatamente disponibili
630 ad una \func{read} chiamata dopo che la \func{write} che li ha scritti è
631 ritornata; ma dati i meccanismi di caching non è detto che tutti i filesystem
632 supportino questa capacità.
634 Se \var{count} è zero la funzione restituisce zero senza fare nient'altro. Per
635 i file ordinari il numero di byte scritti è sempre uguale a quello indicato
636 da \var{count}, a meno di un errore. Negli altri casi si ha lo stesso
637 comportamento di \func{read}.
639 Anche per \func{write} lo standard Unix98 definisce un'analoga \func{pwrite}
640 per scrivere alla posizione indicata senza modificare la posizione corrente
641 nel file, il suo prototipo è:
642 \begin{prototype}{unistd.h}
643 {ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)}
645 Cerca di scrivere sul file \var{fd}, a partire dalla posizione \var{offset},
646 \var{count} byte dal buffer \var{buf}.
648 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e -1
649 in caso di errore, nel qual caso \var{errno} viene settata secondo i valori
650 già visti per \func{write} e \func{lseek}.}
652 \noindent e per essa valgono le stesse considerazioni fatte per \func{pread}.
655 \section{Caratteristiche avanzate}
656 \label{sec:file_adv_func}
658 In questa sezione approfondiremo alcune delle caratteristiche più sottili
659 della gestione file in un sistema unix-like, esaminando in dettaglio il
660 comportamento delle funzioni base, inoltre tratteremo le funzioni che
661 permettono di eseguire alcune operazioni avanzate con i file (il grosso
662 dell'argomento sarà comunque affrontato in \capref{cha:file_advanced}).
665 \subsection{La condivisione dei files}
666 \label{sec:file_sharing}
668 In \secref{sec:file_fd} abbiamo descritto brevemente l'architettura
669 dell'interfaccia coi file da parte di un processo, mostrando in
670 \figref{fig:file_proc_file} le principali strutture usate dal kernel;
671 esamineremo ora in dettaglio le conseguenze che questa architettura ha nei
672 confronti dell'accesso allo stesso file da parte di processi diversi.
676 \includegraphics[width=13cm]{img/filemultacc}
677 \caption{Schema dell'accesso allo stesso file da parte di due processi
679 \label{fig:file_mult_acc}
682 Il primo caso è quello in cui due processi diversi che aprono lo stesso file
683 su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una
684 situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun
685 processo avrà una sua voce nella \textit{file table} referenziata da un
686 diverso file descriptor nella sua \var{file\_struct}. Entrambe le voci nella
687 \textit{file table} faranno però riferimento allo stesso inode su disco.
689 Questo significa che ciascun processo avrà la sua posizione corrente sul file,
690 la sua modalità di accesso e versioni proprie di tutte le proprietà che
691 vengono mantenute nella sua voce della \textit{file table}. Questo ha
692 conseguenze specifiche sugli effetti della possibile azione simultanea sullo
693 stesso file, in particolare occorre tenere presente che:
695 \item ciascun processo può scrivere indipendentemente; dopo ciascuna
696 \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
697 scrittura eccede la dimensione corrente del file questo verrà esteso
698 automaticamente con l'aggiornamento del campo \var{i\_size} nell'inode.
699 \item se un file è in modalità \macro{O\_APPEND} tutte le volte che viene
700 effettuata una scrittura la posizione corrente viene prima settata alla
701 dimensione corrente del file letta dall'inode. Dopo la scrittura il file
702 viene automaticamente esteso.
703 \item l'effetto di \func{lseek} è solo quello di cambiare il campo \var{f\_pos}
704 nella struttura \var{file} della \textit{file table}, non c'è nessuna
705 operazione sul file su disco. Quando la si usa per porsi alla fine del file
706 la posizione viene settata leggendo la dimensione corrente dall'inode.
711 \includegraphics[width=13cm]{img/fileshar}
712 \caption{Schema dell'accesso ai file da parte di un processo figlio}
713 \label{fig:file_acc_child}
716 Il secondo caso è quello in cui due file descriptor di due processi diversi
717 puntino alla stessa voce nella \textit{file table}; questo è ad esempio il
718 caso dei file aperti che vengono ereditati dal processo figlio all'esecuzione
719 di una \func{fork} (si ricordi quanto detto in \secref{sec:proc_fork}). La
720 situazione è illustrata in \figref{fig:file_acc_child}; dato che il processo
721 figlio riceve una copia dello spazio di indirizzi del padre, riceverà anche
722 una copia di \var{file\_struct} e relativa tabella dei file aperti.
724 In questo modo padre e figlio avranno gli stessi file descriptor che faranno
725 riferimento alla stessa voce nella \textit{file table}, condividendo così la
726 posizione corrente sul file. Questo ha le conseguenze descritte a suo tempo in
727 \secref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
728 corrente nel file varierà per entrambi i processi (in quanto verrà modificato
729 \var{f\_pos} che è la stesso per entrambi).
731 Si noti inoltre che anche i flag di stato del file (quelli settati
732 dall'argomento \param{flag} di \func{open}) essendo tenuti nella voce della
733 \textit{file table}\footnote{per la precisione nel campo \var{f\_flags} di
734 \var{file}.}, vengono in questo caso condivisi. Ai file però sono associati
735 anche altri flag, dei quali l'unico usato al momento è \macro{FD\_CLOEXEC},
736 detti \textit{file descriptor flags}. Questi ultimi sono tenuti invece in
737 \var{file\_struct}, e perciò sono specifici di ciascun processo e non vengono
738 modificati dalle azioni degli altri anche in caso di condivisione della stessa
739 voce della \textit{file table}.
743 \subsection{Operazioni atomiche coi file}
744 \label{sec:file_atomic}
746 Come si è visto in un sistema unix è sempre possibile per più processi
747 accedere in contemporanea allo stesso file, e che le operazioni di lettura e
748 scrittura possono essere fatte da ogni processo in maniera autonoma in base
749 ad una posizione corrente nel file che è locale a ciascuno di essi.
751 Se dal punto di vista della lettura dei dati questo non comporta nessun
752 problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
753 maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
754 di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
755 utilizzare meccanismi di sincronizzazione più complessi (come il \textit{file
756 locking}, che esamineremo in \secref{cha:file_advanced}).
758 Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
759 vari processi devono scrivere alla fine di un file (ad esempio un file di
760 log). Come accennato in \secref{sec:file_lseek} settare la posizione alla fine
761 del file e poi scrivere può condurre ad una \textit{race condition}: infatti
762 può succedere che un secondo processo scriva alla fine del file fra la
763 \func{lseek} e la \func{write}; in questo caso, come abbiamo appena visto, il
764 file sarà esteso, ma il nostro primo processo avrà ancora la posizione
765 corrente settata con la \func{lseek} che non corrisponde più alla fine del
766 file, e la successiva \func{write} sovrascriverà i dati del secondo processo.
768 Il problema è che usare due system call in successione non è un'operazione
769 atomica; il problema è stato risolto introducendo la modalità
770 \macro{O\_APPEND}. In questo caso infatti, come abbiamo descritto in
771 precedenza, è il kernel che aggiorna automaticamente la posizione alla fine
772 del file prima di effettuare la scrittura, e poi estende il file. Tutto questo
773 avviene all'interno di una singola system call (la \func{write}) che non
774 essendo interrompibile da un altro processo costituisce un'operazione atomica.
776 Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
777 creare un file di lock, bloccandosi se il file esiste. In questo caso la
778 sequenza logica porterebbe a verificare prima l'esistenza del file con una
779 \func{stat} per poi crearlo con una \func{creat}; di nuovo avremmo la
780 possibilità di una race condition da parte di un altro processo che crea lo
781 stesso file fra il controllo e la creazione.
783 Per questo motivo sono stati introdotti pe \func{open} i due flag
784 \macro{O\_CREAT} e \macro{O\_EXCL}. In questo modo l'operazione di controllo
785 dell'esistenza del file (con relativa uscita dalla funzione con un errore) e
786 creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno
787 di una singola system call.
790 \subsection{La funzioni \func{sync} e \func{fsync}}
791 \label{sec:file_sync}
793 Come accennato in \secref{sec:file_close} tutte le operazioni di scrittura
794 sono in genere bufferizzate dal kernel, che provvede ad effettuarle in maniera
795 asincrona (ad esempio accorpando gli accessi alla stessa zona del disco) in un
796 secondo tempo rispetto al momento della esecuzione della \func{write}.
798 Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
799 sistema mette a disposizione delle funzioni che provvedono a forzare lo
800 scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
801 questo da la garanzia assoluta che i dati siano integri dopo la chiamata,
802 l'hardware dei dischi è in genere dotato di un suo meccanismo interno che
803 può ritardare ulteriormente la scrittura effettiva.} La prima di queste
804 funzioni è \func{sync} il cui prototipo è:
805 \begin{prototype}{unistd.h}{int sync(void)}
807 Sincronizza il buffer della cache dei file col disco.
809 \bodydesc{La funzione ritorna sempre zero.}
811 \noindent i vari standard prevedono che la funzione si limiti a far partire
812 le operazioni, ritornando immediatamente; in Linux (dal kernel 1.3.20) invece
813 la funzione aspetta la conclusione delle operazioni di sincronizzazione del
816 La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
817 esplicitamente lo scarico dei dati su disco, o dal demone di sistema
818 \cmd{update} che esegue lo scarico dei dati ad intervalli di tempo fissi: il
819 valore tradizionale per l'update dei dati è ogni 30 secondi, ma in Linux era
820 di 5 secondi; con le nuove versioni poi, è il kernel che si occupa
821 direttamente di tutto quanto.
823 Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
824 sicuri che i dati di un database sono stati registrati su disco) si possono
825 usare le due funzioni \func{fsync} e \func{fdatasync}, i cui prototipi sono:
828 \funcdecl{int fsync(int fd)}
829 Sincronizza dati e metadati del file \param{fd}
830 \funcdecl{int fdatasync(int fd)}
831 Sincronizza i dati del file \param{fd}.
833 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
834 nel qual caso i codici restituiti in \var{errno} sono:
836 \item[\macro{EINVAL}] \param{fd} è un file speciale che non supporta la
839 ed inoltre \macro{EBADF}, \macro{EROFS} e \macro{EIO}.}
842 Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
843 file specificato, ed attendono fino alla conclusione delle operazioni;
844 \func{fsync} forza anche la sincronizzazione dei metadata dell'inode (i dati
845 di \var{fstat} come i tempi del file).
847 Si tenga presente che questo non comporta la sincronizzazione della
848 directory che contiene il file (e scrittura della relativa voce su
849 disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
850 il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
851 il kernel provvede anche alla sincronizzazione automatica delle voci
855 \subsection{La funzioni \func{dup} e \func{dup2}}
858 Abbiamo già visto in \secref{sec:file_sharing} come un processo figlio
859 condivida gli stessi file descriptor del padre; è possibile però ottenere un
860 comportamento analogo all'interno di uno stesso processo \textit{duplicando}
861 un file descriptor. Per far questo si usa la funzione \func{dup} il cui
863 \begin{prototype}{unistd.h}{int dup(int oldfd)}
864 Crea una copia del file descriptor \param{oldfd}.
866 \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
867 -1 in caso di errore, nel qual caso \var{errno} viene settata ad uno dei
870 \item[\macro{EBADF}] \param{oldfd} non è un file aperto.
871 \item[\macro{EMFILE}] si è raggiunto il numero massimo consentito di file
876 La funzione ritorna, come \func{open}, il primo file descriptor libero. Il
877 file descriptor è una copia esatta del precedente ed entrambi possono essere
878 interscambiati nell'uso. Per capire meglio il funzionamento della funzione si
879 può fare riferimento a \figref{fig:file_dup}: l'effetto della funzione è
880 semplicemente quello di copiare il valore nella struttura \var{file\_struct},
881 cosicché anche il nuovo file descriptor fa riferimento alla stessa voce
882 nella \textit{file table}.
885 \centering \includegraphics[width=13cm]{img/filedup}
886 \caption{Schema dell'accesso ai file duplicati}
890 In questo modo entrambi i file condivideranno eventuali lock, \textit{file
891 status flag}, e posizione corrente: se ad esempio \func{lseek} modifica la
892 posizione su uno dei due file descriptor essa sarà modificata anche sull'altro
893 (al solito viene modificato lo stesso campo nella voce della \textit{file
894 table} a cui entrambi fanno riferimento).
896 L'unica differenza fra i due file descriptor è che ciascuno avrà il suo
897 \textit{file descriptor flag}: nel caso di \func{dup} il flag di \textit{close
898 on exec} viene sempre cancellato nella copia.
900 Una diversa versione della funzione, \func{dup2} viene utilizzata per
901 specificare esplicitamente il nuovo file descriptor; il suo prototipo è:
902 \begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
904 Rende \param{newfd} una copia del file descriptor \param{oldfd}.
906 \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
907 -1 in caso di errore, nel qual caso \var{errno} viene settata ad uno dei
910 \item[\macro{EBADF}] \param{oldfd} non è un file aperto o \param{newfd} ha un
911 valore fuori dall'intervallo consentito per i file descriptor.
912 \item[\macro{EMFILE}] si è raggiunto il numero massimo consentito di file
916 \noindent la funzione chiude il file descriptor \param{newfd} se è aperto.
918 La duplicazione dei file descriptor può essere effettuata anche usando la
919 funzione di controllo dei file \func{fnctl} (che esamineremo in
920 \secref{sec:file_fcntl}) con il parametro \macro{F\_DUPFD}.
922 L'operazione ha la sintassi \code{fnctl(oldfd, F\_DUPFD, newfd)} e se si usa 0
923 come valore per \param{newfd} diventa equivalente a \func{dup}. La sola
924 differenza, a parte i codici di errore, è che \func{dup2} chiude il nuovo file
925 se è già aperto mentre \func{fcntl} apre il primo disponibile con un valore
926 superiore, per cui per poterla usare come \func{dup2} occorrerebbe prima
927 effettuare una \func{close}, perdendo l'atomicità dell'operazione.
929 L'uso principale di queste funzioni è per la redirezione dell'input e
930 dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec};
931 diventa così possibile associare un file (o una pipe) allo standard input o
932 allo standard output, torneremo su questo uso in \secref{sec:ipc_pipes} quando
936 \subsection{La funzione \func{fcntl}}
937 \label{sec:file_fcntl}
939 Oltre alle operazioni base esaminate in \secref{sec:file_base_func} esistono
940 tutta una serie di operazioni ausiliarie che è possibile eseguire su un file
941 descriptor. Per queste operazioni di manipolazione delle varie proprietà di un
942 file descriptor viene usata la funzione \func{fcntl} il cui prototipo è:
946 \funcdecl{int fcntl(int fd, int cmd)}
947 \funcdecl{int fcntl(int fd, int cmd, long arg)}
948 \funcdecl{int fcntl(int fd, int cmd, struct flock * lock)}
949 Esegue una delle possibili operazioni specificate da \param{cmd}
952 \bodydesc{La funzione ha valori di ritorno diversi a seconda
953 dell'operazione. In caso di errore il valore di ritorno è -1 e la
954 variabile \var{errno} viene settata ad un opportuno codice, quelli validi
957 \item[\macro{EBADF}] \param{oldfd} non è un file aperto.
961 Il comportamento di questa funzione è determinato dal valore del comando
962 \param{cmd} che le viene fornito; in \secref{sec:file_dup} abbiamo incontrato
963 un esempio per la duplicazione dei file descriptor, una lista dei possibili
964 valori è riportata di seguito:
965 \begin{basedescript}{\desclabelwidth{2.0cm}}
966 \item[\macro{F\_DUPFD}] trova il primo file descriptor disponibile di valore
967 maggiore o uguale ad \param{arg} e ne fa una copia di \var{fd}. In caso di
968 successo ritorna il nuovo file descriptor. Gli errori possibili sono
969 \macro{EINVAL} se \param{arg} è negativo o maggiore del massimo consentito o
970 \macro{EMFILE} se il processo ha già raggiunto il massimo numero di
971 descrittori consentito.
972 \item[\macro{F\_SETFD}] setta il valore del \textit{file descriptor flag}
973 al valore specificato con \param{arg}. Al momento l'unico bit usato è
974 quello di \textit{close on exec}, identificato dalla costante
976 \item[\macro{F\_GETFD}] ritorna il valore del \textit{file descriptor flag} di
977 \var{fd}, se \macro{FD\_CLOEXEC} è settato i file descriptor aperti vengono
978 chiusi attraverso una \func{exec} altrimenti (il default) restano aperti.
979 \item[\macro{F\_GETFL}] ritorna il valore del \textit{file status flag},
980 permette cioè di rileggere quei bit settati da \func{open} all'apertura del
981 file che vengono memorizzati (quelli riportati nella prima e terza sezione
982 di \tabref{tab:file_open_flags}).
983 \item[\macro{F\_SETFL}] setta il \textit{file status flag} al valore
984 specificato da \param{arg}, possono essere settati solo i bit riportati
985 nella terza sezione di \tabref{tab:file_open_flags} (da verificare).
986 \item[\macro{F\_GETLK}] se un file lock è attivo restituisce nella struttura
987 \param{lock} la struttura \type{flock} che impedisce l'acquisizione del
988 blocco, altrimenti setta il campo \var{l\_type} a \macro{F\_UNLCK} (per i
989 dettagli sul \textit{file locking} vedi \secref{sec:file_locking}).
990 \item[\macro{F\_SETLK}] richiede il file lock specificato da \param{lock} se
991 \var{l\_type} è \macro{F\_RDLCK} o \macro{F\_WRLLCK} o lo rilascia se
992 \var{l\_type} è \macro{F\_UNLCK}. Se il lock è tenuto da qualcun'altro
993 ritorna immediatamente restituendo -1 e setta \var{errno} a \macro{EACCES} o
994 \macro{EAGAIN} (per i dettagli sul \textit{file locking} vedi
995 \secref{sec:file_locking}).
996 \item[\macro{F\_SETLKW}] identica a \macro{F\_SETLK} eccetto per il fatto che
997 la funzione non ritorna subito ma attende che il blocco sia rilasciato. Se
998 l'attesa viene interrotta da un segnale la funzione restituisce -1 e setta
999 \var{errno} a \macro{EINTR} (per i dettagli sul \textit{file locking} vedi
1000 \secref{sec:file_locking}).
1001 \item[\macro{F\_GETOWN}] restituisce il \acr{pid} del processo o il process
1002 group che è preposto alla ricezione dei segnali \macro{SIGIO} e
1003 \macro{SIGURG} per gli eventi associati al file descriptor \var{fd}. Il
1004 process group è restituito come valore negativo.
1005 \item[\macro{F\_SETOWN}] setta il processo o process group che riceverà i
1006 segnali \macro{SIGIO} e \macro{SIGURG} per gli eventi associati al file
1007 descriptor \var{fd}. I process group sono settati usando valori negativi.
1008 \item[\macro{F\_GETSIG}] restituisce il segnale mandato quando ci sono dati
1009 disponibili in input sul file descriptor. Il valore 0 indica il default (che
1010 è \macro{SIGIO}), un valore diverso da zero indica il segnale richiesto,
1011 (che può essere lo stesso \macro{SIGIO}), nel qual caso al manipolatore del
1012 segnale, se installato con \macro{SA\_SIGINFO}, vengono rese disponibili
1013 informazioni ulteriori informazioni.
1014 \item[\macro{F\_SETSIG}] setta il segnale da inviare quando diventa possibile
1015 effettuare I/O sul file descriptor. Il valore zero indica il default
1016 (\macro{SIGIO}), ogni altro valore permette di rendere disponibile al
1017 manipolatore del segnale ulteriori informazioni se si è usata
1018 \macro{SA\_SIGINFO}.
1021 La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
1022 poter essere affrontate in dettaglio a questo punto; saranno riprese più
1023 avanti quando affronteremo le problematiche ad esse relative.
1025 Per determinare le modalità di accesso inoltre è necessario estrarre i bit di
1026 accesso (ottenuti con il comando \macro{F\_GETFL}); infatti la definizione
1027 corrente non assegna bit separati a \macro{O\_RDONLY}, \macro{O\_WRONLY} e
1028 \macro{O\_RDWR},\footnote{posti rispettivamente ai valori 0, 1 e 2.} per cui il
1029 valore si ottiene eseguendo un AND binario del valore di ritorno di
1030 \func{fcntl} con la maschera \macro{O\_ACCMODE} anch'essa definita in
1035 \subsection{La funzione \func{ioctl}}
1036 \label{sec:file_ioctl}
1038 Benché il concetto di \textit{everything is a file} si sia dimostratato molto
1039 valido anche per l'interazione con i più vari dispositivi, con cui si può
1040 interagire con le stesse funzioni usate per i normali file di dati,
1041 esisteranno sempre caratteristiche peculiari, specifiche dell'hardware e della
1042 funzionalità che ciascuno di essi provvede, che non possono venire comprese in
1043 questa interfaccia astratta (un caso tipico è il settaggio della velocità di
1044 una porta seriale, o le dimensioni di un framebuffer).
1046 Per questo motivo l'architettura del sistema ha previsto l'esistenza di una
1047 funzione speciale, \func{ioctl}, con cui poter compiere operazioni specifiche
1048 per ogni singolo dispositivo. Il prototipo di questa funzione è:
1049 \begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
1050 Manipola il dispositivo sottostante, usando il parametro \param{request} per
1051 specificare l'operazione richiesta e il terzo parametro (usualmente di tipo
1052 \param{char * argp}) per il trasferimento dell'informazione necessaria.
1054 \bodydesc{La funzione nella maggior parte dei casi ritorna 0, alcune
1055 operazioni usano però il valore di ritorno per restituire informazioni. In
1056 caso di errore viene sempre restituito -1 e \var{errno} viene settata ad
1057 uno dei valori seguenti:
1059 \item[\macro{ENOTTY}] il file \param{fd} non è associato con un device.
1060 \item[\macro{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
1063 ed inoltre \macro{EBADF} e \macro{EFAULT}.}
1066 La funzione serve in sostanza per fare tutte quelle operazioni che non si
1067 adattano al design dell'architettura dei file e che non è possibile effettuare
1068 con le funzioni esaminate finora. Per questo motivo non è possibile fare altro
1069 che darne una descrizione generica; torneremo ad esaminarla in seguito, quando
1070 si tratterà di applicarla ad alcune problematiche specifiche.
1073 %%% Local Variables:
1075 %%% TeX-master: "gapil"