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