fileunix.tex

   1 \chapter{L'interfaccia unix di I/O con i file}
   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, che non prevede funzioni evolute come la
   7 bufferizzazione o funzioni di lettura o scrittura formattata, ma è su questa
   8 che è costruita anche l'interfaccia standard dei file definita dallo standard
   9 ANSI C.
  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 di implementazione, è comune ad ogni implementazione di unix.
  19 Vedremo cosa comporti questa architettura in caso di accesso contemporaneo ai
  20 file da parte di più processi.
  21
  22
  23 \subsection{L'architettura dei \textit{file descriptors}}
  24 \label{sec:file_fd}
  25
  26 Per poter accedere al contenuto di un file occorre creare un canale di
  27 comunicazione con il kernel che renda possibile operare su di esso (si ricordi
  28 quanto visto in \secref{sec:file_vfs_work}). Questo si fa aprendo il file con
  29 la funzione \func{open} che provvederà a localizzare l'inode del file e
  30 inizializzare le funzioni che il VFS mette a disposizione (riportate in
  31 \tabref{tab:file_file_operations}). Una volta terminate le operazioni, il file
  32 dovrà essere chiuso, e questo chiuderà il canale di comunicazione impedendo
  33 ogni ulteriore operazione.
  34
  35 All'interno di ogni processo i file aperti sono identificati da un intero non
  36 negativo, chiamato appunto \textit{file descriptors}, quando un file viene
  37 aperto la funzione restituisce il file descriptor, e tutte le successive
  38 operazioni devono passare il \textit{file descriptors} come argomento.
  39
  40 Per capire come funziona il meccanismo occorre spiegare a grandi linee come è
  41 che il kernel gestisce l'interazione fra processi e file.  Il kernel mantiene
  42 sempre un elenco dei processi attivi nella cosiddetta \textit{process table}
  43 ed un elenco dei file aperti nella \textit{file table}.
  44
  45 La \textit{process table} è una tabella che contiene una voce per ciascun
  46 processo attivo nel sistema. In Linux la tabella è costituita da strutture di
  47 tipo \var{task\_struct} nelle quali sono raccolte tutte le informazioni
  48 relative ad un singolo processo; fra queste informazioni c'è anche il
  49 puntatore ad una ulteriore struttura di tipo \var{files\_struct} in cui sono
  50 contenute le informazioni relative ai file che il processo ha aperto, ed in
  51 particolare:
  52 \begin{itemize*}
  53 \item i flag relativi ai file descriptor.
  54 \item il numero di file aperti.
  55 \item una tabella che contiene un puntatore alla relativa voce nella
  56   \textit{file table} per ogni file aperto.
  57 \end{itemize*}
  58 il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
  59 questa tabella.
  60
  61 La \textit{file table} è una tabella che contiene una voce per ciascun file
  62 che è stato aperto nel sistema. In Linux è costituita da strutture di tipo
  63 \var{file}; in ciascuna di esse sono tenute varie informazioni relative al
  64 file, fra cui:
  65 \begin{itemize*}
  66 \item lo stato del file (nel campo \var{f\_flags}).
  67 \item il valore della posizione corrente (l'\textit{offset}) nel file.
  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=14cm]{img/procfile.eps}
  82   \caption{Schema della architettura dell'accesso ai file attraverso
  83   l'interfaccia dei \textit{file descroptor}}
  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 ad una linked list, restano i limiti imposti
 146 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
 171 \begin{functions}
 172   \headdecl{sys/types.h}
 173   \headdecl{sys/stat.h}
 174   \headdecl{fcntl.h}
 175   \funcdecl{int open(const char *pathname, int flags)}
 176   \funcdecl{int open(const char *pathname, int flags, mode\_t mode)}
 177   Apre il file indicato da \var{pathname} nella modalità indicata da
 178   \var{flags}, e, nel caso il file sia creato, con gli eventuali permessi
 179   specificati da \var{mode}.
 180
 181   La funzione ritorna il file descriptor in caso di successo e -1 in caso di
 182   errore. In questo caso la variabile \var{errno} viene settata ad uno dei
 183   valori:
 184
 185   \begin{errlist}
 186   \item \macro{EEXIST} \var{pathname} esiste e si è specificato
 187     \macro{O\_CREAT} e \macro{O\_EXCL}.
 188   \item \macro{EISDIR} \var{pathname} indica una directory e si è tentato
 189     l'accesso in scrittura.
 190   \item \macro{ENOTDIR} si è specificato \macro{O\_DIRECTORY} e \var{pathname}
 191     non è una directory.
 192   \item \macro{ENXIO} si sono settati \macro{O\_NOBLOCK} o \macro{O\_WRONLY}
 193     ed il file è una fifo che non viene letta da nessun processo o
 194     \var{pathname} è un file di dispositivo ma il dispositivo è assente.
 195   \item \macro{ENODEV} \var{pathname} si riferisce a un file di dispositivo
 196     che non esiste.
 197   \item \macro{ETXTBSY} si è cercato di accedere in scrittura all'immagine di
 198     un programma in esecuzione.
 199   \item \macro{ELOOP} si sono incotrati troppi link simbolici nel risolvere
 200     pathname o si è indicato \macro{O\_NOFOLLOW} e \var{pathname} è un link
 201     simbolico.
 202   \end{errlist}
 203   ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOENT},
 204   \macro{EROFS}, \macro{EFAULT}, \macro{ENOSPC}, \macro{ENOMEM},
 205   \macro{EMFILE} e \macro{ENFILE}.
 206 \end{functions}
 207
 208 La funzione apre il file, usando il primo file descriptor libero, e crea
 209 l'opportuna voce (cioè la struttura \var{file}) nella file table.  Viene usato
 210 sempre il file descriptor con il valore più basso, questa caratteritica
 211 permette di prevedere qual'è il valore che si otterrà e viene talvolta usata
 212 da alcune applicazioni per sostituire i file corrispondenti ai file standard
 213 di \secref{sec:file_std_descr}: se ad esempio si chiude lo standard input e si
 214 apre subito dopo un nuovo file questo diventerà il nuovo standard input (avrà
 215 cioè il file descriptor 0).
 216
 217 Il nuovo file descriptor non è condiviso con nessun altro processo, (torneremo
 218 sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
 219 \secref{sec:file_sharing}). Il nuovo file descriptor è settato di default per
 220 restare aperto attraverso una \func{exec} (come accennato in
 221 \secref{sec:proc_exec}) ed l'offset è settato all'inizio del file.
 222
 223 Il parametro \var{mode} specifica i permessi con cui il file viene
 224 eventualmente creato; i valori possibili gli stessi già visti in
 225 \secref{sec:file_perm_overview} e possono essere specificati come OR binario
 226 delle costanti descritte in \tabref{tab:file_bit_perm}. Questi permessi
 227 filtrati dal valore di \file{umask} per il processo.
 228
 229 La funzione prevede diverse opzioni, che vengono specificate usando vari bit
 230 del parametro \var{flags}.  Alcuni di questi vanno anche a costituire lo il
 231 flag di stato del file (o \textit{file status flag}), che è mantenuto nel
 232 campo \var{f\_flags} della struttura \var{file} (vedi \curfig).  Questi
 233 bit sono divisi in tre categorie principali:
 234 \begin{itemize}
 235 \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
 236   si accede al file: i valori possibili sono lettura, scrittura o
 237   lettura/scrittura.  Uno di questi bit deve essere sempre specificato quando
 238   si apre un file.  Vengono settati alla chiamata da \func{open}, e possono
 239   essere riletti con una \func{fcntl} (fanno parte del \textit{file status
 240     flag}), ma non modificati.
 241 \item \textsl{i bit delle modalità di apertura}: permettono di specificare
 242   alcuni dei modi di funzionamento di \func{open}. Hanno effetto solo al
 243   momento della chiamata della funzione e non sono memorizzati nè possono
 244   essere riletti.
 245 \item \textsl{i bit delle modalità di operazione}: permettono di specificare
 246   alcuni effetti validi anche in seguito per il comportamento delle operazioni
 247   sul file (come la \func{read} o la \func{write}). Anch'essi fanno parte del
 248   \textit{file status flag}. Il loro valore è settato alla chiamata di
 249   \func{open}, ma possono essere riletti e modificati con una \func{fcntl}.
 250 \end{itemize}
 251
 252 In \ntab\ si sono riportate, ordinate e divise fra loro secondo le tre
 253 modalità appena elencate, le costanti che identificano i vari bit, queste
 254 possono essere combinate con un OR aritmetico per costruire il valore del
 255 parametro \var{flags} da passare alla \func{open} per specificarne il
 256 comportamento.
 257
 258 \begin{table}[!htbp]
 259   \centering
 260   \footnotesize
 261   \begin{tabular}[c]{|l|p{12cm}|}
 262     \hline
 263     \textbf{Flag} & \textbf{Descrizione} \\
 264     \hline
 265     \hline % modailtà di accesso al file
 266     \macro{O\_RDONLY} & apre il file in sola lettura\\
 267     \macro{O\_WRONLY} & apre il file in sola scrittura\\
 268     \macro{O\_RDWR} & apre il file lettura/scrittura\\
 269     \hline % modalita di apertura del file
 270     \hline
 271     \macro{O\_CREAT} & se il file non esiste verrà creato, con le regole di
 272     titolarità del file viste in \secref{sec:file_ownership}. Il parametro
 273     \var{mode} deve essere specificato. \\
 274     \macro{O\_EXCL} & usato in congiunzione con \macro{O\_CREAT} fa sì che
 275     l'esistenza del file diventi un errore\footnote{la man page di \func{open}
 276     segnala che questa opzione è difettosa su NFS, e che i programmi che la
 277     usano per stabilire un file di lock possono incorrere in una race
 278     condition.  Si consiglia come alternativa di usare un file con un nome
 279     univoco e la funzione \func{link} per verificarne l'esistenza.} che fa
 280     fallire \func{open} con \macro{EEXIST}.\\
 281     \macro{O\_NONBLOCK} & apre il file in modalità non bloccante. Questo
 282     valore specifica anche una modalità di operazione (vedi sotto), e
 283     comporta che \func{open} ritorni immediatamente (torneremo su
 284     questo in \secref{sec:file_noblocking}).  \\
 285     \macro{O\_NOCTTY} & se \var{pathname} si riferisce ad un device di
 286     terminale, questo non diventerà il terminale di controllo, anche se il
 287     processo non ne ha ancora uno (si veda \secref{sec:sess_xxx}).\\
 288     \macro{O\_SHLOCK} & opzione di BSD, acquisisce uno shared lock (vedi
 289     \secref{sec:file_locking}) sul file. Non è disponibile in Linux.\\
 290     \macro{O\_EXLOCK} & opzione di BSD, acquisisce uno lock esclusivo (vedi
 291     \secref{sec:file_locking}) sul file. Non è disponibile in Linux.\\
 292     \macro{O\_TRUNC} & se il file esiste ed è un file di dati e la modalità di
 293     apertura consente la scrittura, allora la sua lunghezza verrà troncata a
 294     zero. Se il file è un terminale o una fifo il flag verrà ignorato, negli
 295     altri casi il comportamento non è specificato.\\
 296     \macro{O\_NOFOLLOW} & se \var{pathname} è un link simbolico la chiamata
 297     fallisce. Questa è una estensione BSD aggiunta in Linux dal kernel 2.1.126.
 298     Nelle versioni precedenti i link simbolici sono sempre seguiti, e questa
 299     opzione è ignorata.\\
 300     \macro{O\_DIRECTORY} & se \var{pathname} non è una directory la chiamata
 301     fallisce. Questo flag è specifico di Linux ed è stato introdotto con il
 302     kernel 2.1.126 per evitare dei DoS\footnote{Denial of Service, si chiamano
 303     così attacchi miranti ad impedire un servizio causando una qualche forma
 304     di carico eccessivo per il sistema, che resta bloccato nelle risposte
 305     all'attacco} quando \func{opendir} viene chiamata su una fifo o su un
 306     device di unità a nastri, non deve essere utilizzato al di fuori
 307     dell'implementazione di \func{opendir}. \\
 308     \macro{O\_LARGEFILE} & nel caso di sistemi a 32 bit che supportano file di
 309     grandi dimensioni consente di aprire file le cui dimensioni non possono
 310     essere rappresentate da numeri a 31 bit.\\
 311     \hline
 312     \hline  % modalità di operazione col file
 313     \macro{O\_APPEND} & il file viene aperto in append mode. Prima di ciascuna
 314     scrittura la posizione corrente viene sempre settata alla fine del
 315     file. Può causare corruzione del file con NFS se più di un processo scrive
 316     allo stesso tempo\footnote{il problema è che NFS non supporta la scrittura
 317     in append, ed il kernel deve simularla, ma questo comporta la possibilità
 318     di una race condition}.\\
 319     \macro{O\_NONBLOCK} & il file viene aperto in modalità non bloccante per
 320     le operazioni di I/O: questo significa il fallimento di una \func{read} in
 321     assenza di dati da leggere e quello di una \func{write} in caso di
 322     impossibilità di scrivere immediatamente. L'opzione è effettiva solo per
 323     le fifo e per alcuni file di dispositivo. \\
 324     \macro{O\_NDELAY} & in Linux\footnote{l'opzione origina da SVr4, dove però
 325     causava il ritorno da una \func{read} con un valore nullo e non con un
 326     errore, questo introduce una ambiguità, dato che come vedremo in
 327     \secref{sec:file_read} il ritorno di zero da parte di \func{read} ha il
 328     significato di una end-of-file} è sinonimo di \macro{O\_NONBLOCK}\\
 329     \macro{O\_ASYNC} & apre il file per l'input/output in modalità
 330     asincrona. Non è supportato in Linux. \\
 331     \macro{O\_FSYNC} & \\
 332     \macro{O\_SYNC} & apre il file per l'input/output sincrono, ogni
 333     \func{write} bloccherà fino al completamento della scrittura di tutti dati
 334     sul sull'hardware sottostante\\
 335     \macro{O\_NOATIME} & blocca l'aggiornamento dei tempi dei di accesso dei
 336     file (vedi \secref{sec:file_file_times}). In Linux questa opzione non è
 337     disponibile per il singolo file ma come opzione per il filesystem in fase
 338     di montaggio.\\
 339     \hline
 340   \end{tabular}
 341   \caption{Costanti definite in \file{fcntl.h} per indicare i vari bit
 342     usabili per il specificare parametro \var{flags} di \func{open}.}
 343   \label{tab:file_open_flags}
 344 \end{table}
 345
 346 Nelle prime versioni di unix i flag specificabili per \func{open} erano solo
 347 quelli delle modalità di apertura. Per questo motivo per creare un file c'era
 348 una system call apposita, \func{creat}, il cui prototipo è:
 349
 350 \begin{prototype}{fcntl.h}
 351   {int creat(const char *pathname, mode\_t mode)}
 352   Crea un nuovo file vuoto, con i permessi specificati da \var{mode}. É del
 353   tutto equivalente a \func{open(filedes, O\_CREAT|O\_WRONLY|O\_TRUNC, mode)}.
 354 \end{prototype}
 355
 356 adesso questa funzione resta solo per compatibilità con i vecchi programmi.
 357
 358
 359
 360
 361
 362 \subsection{La funzione \func{close}}
 363 \label{sec:file_close}
 364
 365 \subsection{La funzione \func{lseek}}
 366 \label{sec:file_lseek}
 367
 368 \subsection{La funzione \func{read}}
 369 \label{sec:file_read}
 370
 371 \subsection{La funzione \func{write}}
 372 \label{sec:file_write}
 373
 374
 375 \section{Funzioni avanzate}
 376 \label{sec:file_adv_func}
 377
 378 \subsection{La condivisione dei files}
 379 \label{sec:file_sharing}
 380
 381
 382 Si noti che i flag di stato del file, quelli settati dal parametro \var{flag}
 383 di \func{open}, essendo tenuti nella vode sulla file table, vengono condivisi,
 384 ai file sono però associati anche altri flag, (tenuti invece nella struttura
 385 \var{file\_struct} interna alla process table) che sono unici per ciascun file
 386 descriptor, e sono pertanto detti \textit{file descriptor flags} (l'unico
 387 usato al momento è \macro{FD\_CLOEXEC}).
 388
 389
 390 \subsection{Operazioni atomiche coi file}
 391 \label{sec:file_atomic}
 392
 393
 394 \subsection{La funzioni \func{dup} e \func{dup2}}
 395 \label{sec:file_dup}
 396
 397 \subsection{La funzione \func{fcntl}}
 398 \label{sec:file_fcntl}
 399
 400 \subsection{La funzione \func{ioctl}}
 401 \label{sec:file_ioctl}
 402
 403
 404
 405
 406