X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileunix.tex;h=6f9334df6dbf7e9fe4610bdb76afa858af1ba646;hp=b23698a799fef0888f696ab8eed0df03cfe31ef2;hb=d25090faca15102552d77c38161a8a34b0bac41e;hpb=fd86592a845b5f76ad43ba2374ca0b798ffca595 diff --git a/fileunix.tex b/fileunix.tex index b23698a..6f9334d 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -1,6 +1,6 @@ %% fileunix.tex %% -%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2003 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Prefazione", @@ -50,10 +50,10 @@ Quando un file viene aperto la funzione \func{open} restituisce questo numero, tutte le ulteriori operazioni saranno compiute specificando questo stesso valore come argomento alle varie funzioni dell'interfaccia. -Per capire come funziona il meccanismo occorre spiegare a grandi linee come è -che il kernel gestisce l'interazione fra processi e file. Il kernel mantiene -sempre un elenco dei processi attivi nella cosiddetta \textit{process table} -ed un elenco dei file aperti nella \textit{file table}. +Per capire come funziona il meccanismo occorre spiegare a grandi linee come il +kernel gestisce l'interazione fra processi e file. Il kernel mantiene sempre +un elenco dei processi attivi nella cosiddetta \textit{process table} ed un +elenco dei file aperti nella \textit{file table}. La \textit{process table} è una tabella che contiene una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è costituita da una @@ -300,7 +300,7 @@ usato sempre il file descriptor con il valore pi \func{write} bloccherà fino al completamento della scrittura di tutti dati sul sull'hardware sottostante.\\ \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}. \\ - \const{O\_NOATIME} & blocca l'aggiornamento dei tempi dei di accesso dei + \const{O\_NOATIME} & blocca l'aggiornamento dei tempi di accesso dei file (vedi \secref{sec:file_file_times}). In Linux questa opzione non è disponibile per il singolo file ma come opzione per il filesystem in fase di montaggio.\\ @@ -317,9 +317,10 @@ usato sempre il file descriptor con il valore pi file con un nome univoco e la funzione \func{link} per verificarne l'esistenza (vedi \secref{sec:ipc_file_lock}).} -\footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti - ad impedire un servizio causando una qualche forma di carico eccessivo per - il sistema, che resta bloccato nelle risposte all'attacco.} +\footnotetext[3]{\textit{Denial of Service}\index{DoS}, si chiamano così + attacchi miranti ad impedire un servizio causando una qualche forma di + carico eccessivo per il sistema, che resta bloccato nelle risposte + all'attacco.} \footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed il kernel deve simularla, ma questo comporta la possibilità di una race @@ -335,20 +336,17 @@ descriptor che si otterr alcune applicazioni per sostituire i file corrispondenti ai file standard visti in \secref{sec:file_std_descr}: se ad esempio si chiude lo standard input e si apre subito dopo un nuovo file questo diventerà il nuovo standard -input (avrà cioè il file descriptor 0). - -Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo -sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in -\secref{sec:file_sharing}). Il nuovo file descriptor è impostato per restare -aperto attraverso una \func{exec} (come accennato in \secref{sec:proc_exec}) e -l'offset è impostato all'inizio del file. - -L'argomento \param{mode} specifica i permessi con cui il file viene -eventualmente creato; i valori possibili sono gli stessi già visti in -\secref{sec:file_perm_overview} e possono essere specificati come OR binario -delle costanti descritte in \tabref{tab:file_bit_perm}. Questi permessi sono -filtrati dal valore di \var{umask} (vedi \secref{sec:file_umask}) per il -processo. +input (avrà cioè il file descriptor 0). Il nuovo file descriptor non è +condiviso con nessun altro processo (torneremo sulla condivisione dei file, in +genere accessibile dopo una \func{fork}, in \secref{sec:file_sharing}) ed è +impostato per restare aperto attraverso una \func{exec} (come accennato in +\secref{sec:proc_exec}); l'offset è impostato all'inizio del file. + +L'argomento \param{mode} indica i permessi con cui il file viene creato; i +valori possibili sono gli stessi già visti in \secref{sec:file_perm_overview} +e possono essere specificati come OR binario delle costanti descritte in +\tabref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di +\var{umask} (vedi \secref{sec:file_umask}) per il processo. La funzione prevede diverse opzioni, che vengono specificate usando vari bit dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire @@ -356,33 +354,33 @@ il flag di stato del file (o \textit{file status flag}), che campo \var{f\_flags} della struttura \struct{file} (al solito si veda lo schema di \figref{fig:file_proc_file}). Essi sono divisi in tre categorie principali: -\begin{itemize} +\begin{itemize*} \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità si accederà al file: i valori possibili sono lettura, scrittura o lettura/scrittura. Uno di questi bit deve essere sempre specificato quando si apre un file. Vengono impostati alla chiamata da \func{open}, e possono - essere riletti con una \func{fcntl} (fanno parte del \textit{file status - flag}), ma non possono essere modificati. + essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}), + ma non possono essere modificati. \item \textsl{i bit delle modalità di apertura}: permettono di specificare alcune delle caratteristiche del comportamento di \func{open} quando viene eseguita. Hanno effetto solo al momento della chiamata della funzione e non sono memorizzati né possono essere riletti. \item \textsl{i bit delle modalità di operazione}: permettono di specificare alcune caratteristiche del comportamento delle future operazioni sul file - (come la \func{read} o la \func{write}). Anch'essi fanno parte del - \textit{file status flag}. Il loro valore è impostato alla chiamata di - \func{open}, ma possono essere riletti e modificati (insieme alle - caratteristiche operative che controllano) con una \func{fcntl}. -\end{itemize} + (come \func{read} o \func{write}). Anch'essi fan parte del \textit{file + status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma + possono essere riletti e modificati (insieme alle caratteristiche operative + che controllano) con una \func{fcntl}. +\end{itemize*} -In \tabref{tab:file_open_flags} si sono riportate, ordinate e divise fra loro +In \tabref{tab:file_open_flags} sono riportate, ordinate e divise fra loro secondo le tre modalità appena elencate, le costanti mnemoniche associate a -ciascuno di questi bit. Dette costanti possono essere combinate fra di loro -con un OR aritmetico per costruire il valore (in forma di maschera binaria) -dell'argomento \param{flags} da passare alla \func{open} per specificarne il -comportamento. I due flag \const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono -estensioni specifiche di Linux, e deve essere definita la macro -\macro{\_GNU\_SOURCE} per poterli usare. +ciascuno di questi bit. Dette costanti possono essere combinate fra loro con +un OR aritmetico per costruire il valore (in forma di maschera binaria) +dell'argomento \param{flags} da passare alla \func{open}. I due flag +\const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono estensioni specifiche di +Linux, e deve essere definita la macro \macro{\_GNU\_SOURCE} per poterli +usare. Nelle prime versioni di Unix i valori di \param{flag} specificabili per \func{open} erano solo quelli relativi alle modalità di accesso del file. Per @@ -406,7 +404,7 @@ descriptor ritorna disponibile; il suo prototipo Chiude il descrittore \param{fd}. \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore, - ed in questo caso \var{errno} assumerà uno dei valori: + con \var{errno} che assume i valori: \begin{errlist} \item[\errcode{EBADF}] \param{fd} non è un descrittore valido. \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale. @@ -461,7 +459,7 @@ ad un valore qualsiasi con la funzione \funcd{lseek}, il cui prototipo \funcdecl{off\_t lseek(int fd, off\_t offset, int whence)} Imposta la posizione attuale nel file. - \bodydesc{La funzione ritorna valore della posizione corrente in caso di + \bodydesc{La funzione ritorna il valore della posizione corrente in caso di successo e -1 in caso di errore nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} @@ -491,20 +489,19 @@ seguenti valori\footnote{per compatibilit Come accennato in \secref{sec:file_file_size} con \func{lseek} è possibile impostare la posizione corrente anche oltre la fine del file, e alla -successiva scrittura il file sarà esteso. La chiamata non causa nessuna -attività di input/output, si limita a modificare la posizione corrente nel -kernel (cioè \var{f\_pos} in \param{file}, vedi \figref{fig:file_proc_file}). - -Dato che la funzione ritorna la nuova posizione, usando il valore zero per -\param{offset} si può riottenere la posizione corrente nel file chiamando la -funzione con \code{lseek(fd, 0, SEEK\_CUR)}. +successiva scrittura il file sarà esteso. La chiamata non causa nessun accesso +al file, si limita a modificare la posizione corrente (cioè il valore +\var{f\_pos} in \param{file}, vedi \figref{fig:file_proc_file}). Dato che la +funzione ritorna la nuova posizione, usando il valore zero per \param{offset} +si può riottenere la posizione corrente nel file chiamando la funzione con +\code{lseek(fd, 0, SEEK\_CUR)}. Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che la successiva scrittura avvenga alla fine del file, infatti se questo è stato aperto anche da un altro processo che vi ha scritto, la fine del file può essersi spostata, ma noi scriveremo alla posizione impostata in precedenza -(questa è una potenziale sorgente di \textit{race condition} -\index{race condition}, vedi \secref{sec:file_atomic}). +(questa è una potenziale sorgente di +\textit{race condition}\index{race condition}, vedi \secref{sec:file_atomic}). Non tutti i file supportano la capacità di eseguire una \func{lseek}, in questo caso la funzione ritorna l'errore \errcode{EPIPE}. Questo, oltre che per @@ -521,7 +518,7 @@ indefinito. \label{sec:file_read} -Una volta che un file è stato aperto (con il permesso in lettura) su possono +Una volta che un file è stato aperto (con il permesso in lettura) si possono leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui prototipo è: \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)} @@ -545,24 +542,21 @@ prototipo La funzione tenta di leggere \param{count} byte a partire dalla posizione corrente nel file. Dopo la lettura la posizione sul file è spostata automaticamente in avanti del numero di byte letti. Se \param{count} è zero la -funzione restituisce zero senza nessun altro risultato. - -Si deve sempre tener presente che non è detto che la funzione \func{read} -restituisca sempre il numero di byte richiesto, ci sono infatti varie ragioni -per cui la funzione può restituire un numero di byte inferiore; questo è un -comportamento normale, e non un errore, che bisogna sempre tenere presente. +funzione restituisce zero senza nessun altro risultato. Si deve sempre tener +presente che non è detto che la funzione \func{read} restituisca sempre il +numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione +può restituire un numero di byte inferiore; questo è un comportamento normale, +e non un errore, che bisogna sempre tenere presente. La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte di quanto il file ne contenga. In questo caso il file viene letto fino alla sua fine, e la funzione ritorna regolarmente il numero di byte letti -effettivamente. - -Raggiunta la fine del file, alla ripetizione di un'operazione di lettura, -otterremmo il ritorno immediato di \func{read} con uno zero. La condizione di -raggiungimento della fine del file non è un errore, e viene segnalata appunto -da un valore di ritorno di \func{read} nullo. Ripetere ulteriormente la -lettura non avrebbe nessun effetto se non quello di continuare a ricevere zero -come valore di ritorno. +effettivamente. Raggiunta la fine del file, alla ripetizione di un'operazione +di lettura, otterremmo il ritorno immediato di \func{read} con uno zero. La +condizione di raggiungimento della fine del file non è un errore, e viene +segnalata appunto da un valore di ritorno di \func{read} nullo. Ripetere +ulteriormente la lettura non avrebbe nessun effetto se non quello di +continuare a ricevere zero come valore di ritorno. Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere un numero di byte letti inferiore a quello richiesto, ma questo non è vero @@ -576,20 +570,19 @@ con un numero di byte inferiore a quelli richiesti. Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket\index{socket}, come vedremo in \secref{sec:sock_io_behav}), o per la lettura da certi file di dispositivo, come le unità a nastro, che -restituiscono sempre i dati ad un singolo blocco alla volta. +restituiscono sempre i dati ad un singolo blocco alla volta. In realtà anche le due condizioni segnalate dagli errori \errcode{EINTR} e \errcode{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è bloccata in attesa di dati in ingresso e viene interrotta da un segnale; in tal caso l'azione da intraprendere è quella di rieseguire la funzione. -Torneremo in dettaglio sull'argomento in \secref{sec:sig_gen_beha}. - -La seconda si verifica quando il file è in modalità non bloccante (vedi +Torneremo in dettaglio sull'argomento in \secref{sec:sig_gen_beha}. La +seconda si verifica quando il file è in modalità non bloccante (vedi \secref{sec:file_noblocking}) e non ci sono dati in ingresso: la funzione -allora ritorna immediatamente con un errore \errcode{EAGAIN}\footnote{sotto - BSD per questo errore viene usata la costante \errcode{EWOULDBLOCK}, in - Linux, con le glibc, questa è sinonima di \errcode{EAGAIN}.} che indica -soltanto che occorrerà provare a ripetere la lettura. +allora ritorna immediatamente con un errore \errcode{EAGAIN}\footnote{BSD usa + per questo errore la costante \errcode{EWOULDBLOCK}, in Linux, con le + \acr{glibc}, questa è sinonima di \errcode{EAGAIN}.} che indica soltanto che +occorrerà provare a ripetere la lettura. La funzione \func{read} è una delle system call fondamentali, esistenti fin dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix @@ -612,7 +605,7 @@ posizione \param{offset}, nel buffer \param{buf}. \end{prototype} \noindent che però diventa accessibile solo con la definizione della macro: \begin{verbatim} - #define _XOPEN_SOURCE 500 +#define _XOPEN_SOURCE 500 \end{verbatim} Questa funzione serve quando si vogliono leggere dati dal file senza @@ -645,10 +638,10 @@ scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo chiuso in lettura; in questo caso viene anche generato il segnale \const{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la funzione ritorna questo errore. - \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di - aver potuto scrivere qualsiasi dato. - \item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si - era aperto il file in modalità \const{O\_NONBLOCK}. + \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver + potuto scrivere qualsiasi dato. + \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in + modalità \const{O\_NONBLOCK}. \end{errlist} ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF}, \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori @@ -712,7 +705,7 @@ confronti dell'accesso allo stesso file da parte di processi diversi. \label{fig:file_mult_acc} \end{figure} -Il primo caso è quello in cui due processi diversi che aprono lo stesso file +Il primo caso è quello in cui due processi diversi aprono lo stesso file su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun processo avrà una sua voce nella \textit{file table} referenziata da un