fileunix.tex

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