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