\label{sec:file_unix_interface}
-Come visto in sez.~\ref{sec:file_vfs_work} il kernel mette a disposione
+Come visto in sez.~\ref{sec:file_vfs_work} il kernel mette a disposizione
tramite il \itindex{Virtual~File~System} \textit{Virtual File System} una
serie di \textit{system call} che consentono di operare sui file in maniera
generale. Abbiamo trattato quelle relative alla gestione delle proprietà dei
fig.~\ref{fig:kstruct_file}, contengono le informazioni necessarie per la
gestione dei file, ed in particolare:
\begin{itemize*}
-\item il flag di stato \itindex{file~status~flag} del file nel campo
+\item i flag di stato \itindex{file~status~flag} del file nel campo
\var{f\_flags}.
\item la posizione corrente nel file, il cosiddetto \textit{offset}, nel campo
\var{f\_pos}.
\end{itemize*}
In questa infrastruttura un \textit{file descriptor} non è altro che l'intero
-positivo che indicizza quest'ultima tabella, grazie al quale si può recuperare
-il puntatore alla struttura \kstruct{file} nella \itindex{file~table}
-\textit{file table} corrispondente al file che è stato aperto dal processo e a
-cui era stato assegnato questo indice. Ma una volta indicato col \textit{file
- descriptor} qual'è la struttura \kstruct{file} nella \textit{file table}
-corrispondente al file voluto, il kernel potrà usare le funzioni messe
-disposizione dal VFS per eseguire sul file tutte le operazioni necessarie.
+positivo che indicizza quest'ultima tabella, e che consente di recuperare il
+puntatore alla struttura \kstruct{file} corrispondente al file aperto dal
+processo a cui era stato assegnato questo indice. Una volta ottenuta grazie
+al \textit{file descriptor} la struttura \kstruct{file} corrispondente al file
+voluto nella \itindex{file~table} \textit{file table}, il kernel potrà usare
+le funzioni messe disposizione dal VFS per eseguire sul file tutte le
+operazioni necessarie.
Il meccanismo dell'apertura dei file prevede che venga sempre fornito il primo
\textit{file descriptor} libero nella tabella, e per questo motivo essi
vengono assegnati in successione tutte le volte che si apre un nuovo file,
posto che non ne sia stato chiuso nessuno in precedenza.
-In tutti i sistemi unix-like esiste poi una convenzione generale per cui ogni
-processo viene lanciato dalla shell con almeno tre file aperti. Questi, per
-quanto appena detto, avranno come \itindex{file~descriptor} \textit{file
- descriptor} i valori 0, 1 e 2. Benché questa sia soltanto una convenzione,
-essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe
-portare a gravi problemi di interoperabilità.
-
-Il primo file è sempre associato al cosiddetto \itindex{standard~input}
-\textit{standard input}, è cioè il file da cui un processo si aspetta di dover
-leggere i dati in ingresso. Il secondo file è il cosiddetto
-\itindex{standard~output} \textit{standard output}, cioè quello su cui ci si
-aspetta di dover scrivere i dati in uscita. Il terzo è lo
+In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
+processo si aspetta di avere sempre tre file aperti che, per quanto appena
+detto, avranno come \itindex{file~descriptor} \textit{file descriptor} i
+valori 0, 1 e 2. Il primo file è sempre associato al cosiddetto
+\itindex{standard~input} \textit{standard input}, è cioè il file da cui un
+processo si aspetta di dover leggere i dati in ingresso. Il secondo file è il
+cosiddetto \itindex{standard~output} \textit{standard output}, cioè quello su
+cui ci si aspetta di dover scrivere i dati in uscita. Il terzo è lo
\itindex{standard~error} \textit{standard error}, su cui vengono scritti i
-dati relativi agli errori. Nel caso della shell tutti questi file sono
-associati al terminale di controllo, e corrispondono quindi alla lettura della
-tastiera per l'ingresso e alla scrittura sul terminale per l'uscita. Lo
-standard POSIX.1 provvede, al posto dei valori numerici, tre costanti
-simboliche, definite in tab.~\ref{tab:file_std_files}.
+dati relativi agli errori.
+
+Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte
+delle applicazioni, e non aderirvi potrebbe portare a problemi di
+interoperabilità. Nel caso della shell tutti questi file sono associati al
+terminale di controllo, e corrispondono quindi alla lettura della tastiera per
+l'ingresso e alla scrittura sul terminale per l'uscita. Lo standard POSIX.1
+provvede, al posto dei valori numerici, tre costanti simboliche, definite in
+tab.~\ref{tab:file_std_files}.
\begin{table}[htb]
\centering
error}\\
\hline
\end{tabular}
- \caption{Costanti definite in \headfile{unistd.h} per i file standard aperti
- alla creazione di ogni processo.}
+ \caption{Costanti definite in \headfile{unistd.h} per i file standard.}
\label{tab:file_std_files}
\end{table}
Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
numero di file aperti era anche soggetto ad un limite massimo dato dalle
dimensioni del vettore di puntatori con cui era realizzata la tabella dei file
-descriptor dentro \kstruct{files\_struct}; questo limite intrinseco nei kernel
+descriptor dentro \kstruct{files\_struct}. Questo limite intrinseco nei kernel
più recenti non sussiste più, dato che si è passati da un vettore ad una
lista, ma restano i limiti imposti dall'amministratore (vedi
sez.~\ref{sec:sys_limits}).
\errval{EROFS}, nel loro significato generico.}
\end{funcproto}
-La funzione apre il file indicato da \param{pathname} nella modalità indicata da
-\param{flags}. Essa può essere invocata in due modi diversi, specificando
+La funzione apre il file indicato da \param{pathname} nella modalità indicata
+da \param{flags}. Essa può essere invocata in due modi diversi, specificando
opzionalmente un terzo argomento \param{mode}. Qualora il file non esista e
venga creato, questo argomento consente di indicare quali permessi dovranno
essergli assegnati. I valori possibili sono gli stessi già visti in
comunque filtrati dal valore della \itindex{umask} \textit{umask} (vedi
sez.~\ref{sec:file_perm_management}) del processo.
-La funzione restituisce sempre il primo file descriptor libero, e questa
-caratteristica permette di prevedere qual è il valore del file descriptor che
-si otterrà al ritorno di \func{open}, e viene spesso usata dalle applicazioni
-per sostituire i file corrispondenti ai file standard visti in
+La funzione restituisce sempre il primo file descriptor libero, una
+caratteristica che permette di prevedere qual è il valore del file descriptor
+che si otterrà al ritorno di \func{open}, e che viene spesso usata dalle
+applicazioni per sostituire i file corrispondenti ai file standard visti in
tab.~\ref{tab:file_std_files}. Se ad esempio si chiude lo
\itindex{standard~input} \textit{standard input} e si apre subito dopo un
nuovo file questo diventerà il nuovo \itindex{standard~input} \textit{standard
- input} (avrà cioè il file descriptor 0).
+ input} dato che avrà il file descriptor 0.
Al momento dell'apertura il nuovo file descriptor non è condiviso con nessun
altro processo (torneremo sul significato della condivisione dei file
esso direttamente tramite il file descriptor, e quanto avviene al
\textit{pathname} con cui lo si è aperto sarà del tutto ininfluente.
-Il comportamento della funzione e le diverse modalità con cui può essere
-aperto il file vengono controllati dall'argomento \param{flags} il cui valore
+Il comportamento della funzione, e le diverse modalità con cui può essere
+aperto il file, vengono controllati dall'argomento \param{flags} il cui valore
deve essere indicato come maschera binaria in cui ciascun bit ha un
significato specifico. Alcuni di questi bit vanno anche a costituire i
-cosiddetti \textsl{flag di stato} del file (o \itindex{file~status~flag}
-\textit{file status flags}), che vengono mantenuti nel campo \var{f\_flags}
-della struttura \kstruct{file} che abbiamo riportato anche in
-fig.~\ref{fig:file_proc_file}).
+cosiddetti \textsl{flag di stato} del file (i cosiddetti
+\itindex{file~status~flag} \textit{file status flags}), che vengono mantenuti
+nel campo \var{f\_flags} della struttura \kstruct{file} che abbiamo riportato
+anche in fig.~\ref{fig:file_proc_file}).
Ciascun flag viene identificato da una apposita costante, ed il valore
di \param{flags} deve essere specificato come OR aritmetico di queste
non si ha a che fare con singoli bit separati dell'argomento \param{flags}, ma
con un numero composto da due bit. Questo significa ad esempio che la
combinazione \code{\const{O\_RDONLY}|\const{O\_WRONLY}} non è affatto
-equivalente a \const{O\_WRONLY}, e non deve essere usata.\footnote{in realtà
+equivalente a \const{O\_RDWR}, e non deve essere usata.\footnote{in realtà
su Linux, dove i valori per le tre costanti di
tab.~\ref{tab:open_access_mode_flag} sono rispettivamente $0$, $1$ e $2$, il
- valore $3$ viene usato con un significato speciale ed assolutamente fuori
+ valore $3$ viene usato con un significato speciale, ed assolutamente fuori
standard, disponibile solo per i file di dispositivo e solo per alcuni
driver, in cui si richiede la verifica della capacità di accesso in lettura
e scrittura ma viene restituito un file descriptor che non può essere letto
\const{O\_ACCMODE}, ma non può essere modificato. Nella \acr{glibc} sono
definite inoltre \const{O\_READ} come sinonimo di \const{O\_RDONLY} e
\const{O\_WRITE} come sinonimo di \const{O\_WRONLY}.\footnote{si tratta di
- definizioni completamente fuori standard, attinenti insieme a
- \const{O\_EXEC}, che permetterebbe l'apertura di un file per l'esecuzione,
- ad un non meglio precisato ``\textit{GNU system}''; pur essendo equivalenti
+ definizioni completamente fuori standard, attinenti, insieme a
+ \const{O\_EXEC} che permetterebbe l'apertura di un file per l'esecuzione, ad
+ un non meglio precisato ``\textit{GNU system}''; pur essendo equivalenti
alle definizioni classiche non è comunque il caso di utilizzarle.}
Il secondo gruppo di flag è quello delle \textsl{modalità di
associato ad una unità a nastri. Non viene
usato al di fuori dell'implementazione di
\func{opendir}, ed è utilizzabile soltanto se si è
- definata la macro \macro{\_GNU\_SOURCE}.\\
+ definita la macro \macro{\_GNU\_SOURCE}.\\
\const{O\_EXCL} & Deve essere usato in congiunzione con
\const{O\_CREAT} ed in tal caso impone che il file
indicato da \param{pathname} non sia già esistente
illustrato in sez.~\ref{sec:intro_gcc_glibc_std} è
sempre preferibile usare la conversione automatica
delle funzioni che si attiva assegnando a $64$ la
- macro \macro{\_FILE\_OFFSET\_BITS} e non usare mai
+ macro \macro{\_FILE\_OFFSET\_BITS}, e non usare mai
questo flag.\\
\const{O\_NOCTTY} & Se \param{pathname} si riferisce ad un dispositivo
di terminale, questo non diventerà il terminale di
\const{O\_NOFOLLOW} & Se \param{pathname} è un collegamento simbolico
la chiamata fallisce. Questa è un'estensione BSD
aggiunta in Linux a partire dal kernel
- 2.1.126 ed utilizzabile soltanto se si è definata
+ 2.1.126, ed utilizzabile soltanto se si è definita
la macro \macro{\_GNU\_SOURCE}.\\
\const{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
ne tronca la lunghezza a zero; con un terminale o
precedenti la funzionalità viene emulata controllando prima l'esistenza del
file per cui usarla per creare \index{file!di lock} un file di lock potrebbe
dar luogo a una \itindex{race~condition} \textit{race condition}.\footnote{un
- file potrebbe venir creato fra il controllo la successiva apertura
+ file potrebbe venir creato fra il controllo la successiva apertura con
\const{O\_CREAT}, la cosa si può risolvere comunque creando un file con un
nome univoco ed usando la funzione \func{link} per creare il \index{file!di
lock} file di lock, (vedi sez.~\ref{sec:ipc_file_lock}).}
Se si usa \const{O\_EXCL} senza \const{O\_CREAT} il comportamento è
indefinito. Nella creazione di un file con \const{O\_CREAT} occorre sempre
specificare l'argomento di \param{mode}, che altrimenti è ignorato. Si tenga
-presente che indipendentemente dai permessi che si possono assegnare, che
-potrebbero non consentire in seguito lettura o scrittura, quando il file viene
+presente che indipendentemente dai permessi che si possono assegnare, che in
+seguito potrebbero non consentire lettura o scrittura, quando il file viene
aperto l'accesso viene garantito secondo quanto richiesto con i flag di
tab.~\ref{tab:open_access_mode_flag}. Quando viene creato un nuovo file
\const{O\_CREAT} con tutti e tre i tempi del file di
impostato viene generato il segnale \signal{SIGIO}
tutte le volte che il file è pronto per le
operazioni di lettura o scrittura. Questo flag si
- può usare solo terminali, pseudoterminali e socket
+ può usare solo terminali, pseudo-terminali e socket
e, a partire dal kernel 2.6, anche sulle fifo.\\
\const{O\_CLOEXEC}& Attiva la modalità di \itindex{close-on-exec}
\textit{close-on-exec} (vedi
una \func{read} con un valore nullo e non con un
errore, questo introduce un'ambiguità, dato che
come vedremo in sez.~\ref{sec:file_read} il ritorno
- di un valore nulla da parte di \func{read} ha
+ di un valore nullo da parte di \func{read} ha
il significato di una \textit{end-of-file}.\\
\const{O\_SYNC} & Apre il file per l'input/output sincrono. Ogni
+ scrittura si bloccherà fino alla conferma
+ dell'arrivo di tutti i dati e di tutti i metadati
+ sull'hardware sottostante (in questo significato
+ solo dal kernel 2.6.33).\\
+ \const{O\_DSYNC} & Apre il file per l'input/output sincrono. Ogni
scrittura di dati si bloccherà fino alla conferma
- dell'arrivo di tutti i dati sull'hardware
- sottostante.\\
+ dell'arrivo degli stessi e della parte di metadati
+ ad essi relativa sull'hardware sottostante (in
+ questo significato solo dal kernel 2.6.33).\\
\hline
\end{tabular}
\caption{Le costanti che identificano le \textit{modalità di operazione} di
\label{tab:open_operation_flag}
\end{table}
-
Il terzo gruppo è quello dei flag delle \textsl{modalità di operazione},
riportati in tab.~\ref{tab:open_operation_flag}, che permettono di specificare
varie caratteristiche del comportamento delle operazioni di I/O che verranno
\var{f\_flags} della struttura \kstruct{file} insieme al valore della
\textsl{modalità di accesso} andando far parte dei cosiddetti \textit{file
status flags}. Il loro valore viene impostato alla chiamata di \func{open},
-ma possono essere riletti ed in alcuni anche modificati, con conseguente
-effetto sulle caratteristiche operative che controllano, con \func{fcntl}
-(vedi sez.~\ref{sec:file_fcntl}).
+ma possono essere riletti ed in alcuni di essi anche modificati, con
+conseguente effetto sulle caratteristiche operative che controllano, con
+\func{fcntl} (vedi sez.~\ref{sec:file_fcntl}).
Il flag \const{O\_DIRECT} non è previsto da nessuno standard, anche se è
presente in alcuni kernel unix-like.\footnote{il flag è stato introdotto dalla
allineati alle dimensioni dei blocchi del filesystem. Con il kernel 2.6 in
genere basta che siano allineati a multipli di 512 byte, ma le restrizioni
possono variare a seconda del filesystem, ed inoltre su alcuni filesystem può
-non essere supportato nel qual caso si avrà un errore di \errval{EINVAL}.
+non essere supportato, nel qual caso si avrà un errore di \errval{EINVAL}.
Lo scopo di \const{O\_DIRECT} è consentire un completo controllo sulla
bufferizzazione dei propri dati per quelle applicazioni (in genere database)
eventuale mappatura in memoria del file (vedi sez.~\ref{sec:file_memory_map}).
Si tenga presente infine che anche se l'uso di \const{O\_DIRECT} comporta
-sostanzialmente una scrittura sincrona dei dati dei buffer in \textit{user
- space}, questo non è completamente equivalente all'uso di \const{O\_SYNC}
-che garantisce anche sulla scrittura sincrona dei metadati associati alla
-scrittura dei dati del file. Per questo in genere è opportuno se si usa
-\const{O\_DIRECT} è opportuno richiedere anche \const{O\_SYNC}.
+sostanzialmente solo una scrittura sincrona dei dati dei buffer in
+\textit{user space}, questo non è completamente equivalente all'uso di
+\const{O\_SYNC} che garantisce anche sulla scrittura sincrona dei metadati
+associati alla scrittura dei dati del file. Per questo in genere è opportuno
+se si usa \const{O\_DIRECT} è opportuno richiedere anche \const{O\_SYNC}.
Si tenga presente infine che la implementazione di \const{O\_SYNC} di Linux
differisce da quanto previsto dallo standard POSIX.1 che prevede, oltre a
informazioni ausiliarie come i tempi dei file.
Il secondo, da usare in combinazione con \const{O\_SYNC} o \const{O\_DSYNC} ne
-sospende l'effetto, consentento al kernel di bufferizzare le scritture, ma
+sospende l'effetto, consentendo al kernel di bufferizzare le scritture, ma
soltanto finché non avviene una lettura, in quel caso i dati ed i metadati
-dovranno essere sincronizzati (secondo le modalità indicate da \const{O\_SYNC}
-e \const{O\_DSYNC}) e la lettura verrà bloccata fintanto che detta
-sincronizzazione non sia completata.
-
-Nel caso di Linux fino al kernel 2.6.33 la sola semantica supportata era
-quella di \const{O\_DSYNC} o
-
- \const{O\_DSYNC}
-
-
-e \const{O\_RSYNC}
-erano sinoni
-
-
-che una lettura si blocchi
-
-
-
- \const{O\_DSYNC} Variante di I/O sincrono definita da POSIX; presente
- dal kernel 2.1.130 come sinonimo di
- \const{O\_SYNC}.
-
-
- \const{O\_RSYNC} Variante analoga alla precedente, trattata allo
- stesso modo.
-
-
-
-
+dovranno essere sincronizzati immediatamente (secondo le modalità indicate da
+\const{O\_SYNC} e \const{O\_DSYNC}) e la lettura verrà bloccata fintanto che
+detta sincronizzazione non sia completata.
+Nel caso di Linux, fino al kernel 2.6.33, esisteva solo \const{O\_SYNC}, ma
+con il comportamento previsto dallo standard per \const{O\_DSYNC}, e sia
+questo che \const{O\_RSYNC} erano definiti (fin dal kernel 2.1.130) come
+sinonimi di \const{O\_SYNC}. Con il kernel 2.6.33 il significato di
+\const{O\_SYNC} è diventato quello dello standard, ma gli è stato assegnato un
+valore diverso, mantenendo quello originario, con il comportamento
+corrispondete, per \const{O\_DSYNC}.
-%TODO trattare le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
-% nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
+% NOTE: per le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
+% nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
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
-questo motivo per creare un nuovo file c'era una system call apposita,
-\funcd{creat}, il cui prototipo è:
+questo motivo per creare un nuovo file c'era una \textit{system call}
+apposita, \funcd{creat}, nel caso di Linux questo non è più necessario ma la
+funzione è definita ugualmente; il suo prototipo è:
\begin{funcproto}{
\fhead{fcntl.h}
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà gli stessi valori che si otterebbero con
+ caso \var{errno} assumerà gli stessi valori che si otterrebbero con
\func{open}.}
\end{funcproto}
-
La funzione crea un nuovo file vuoto, con i permessi specificati
dall'argomento \param{mode}. È del tutto equivalente a \code{open(filedes,
O\_CREAT|O\_WRONLY|O\_TRUNC, mode)} e resta solo per compatibilità con i
\subsection{La funzione \func{close}}
\label{sec:file_close}
-La funzione \funcd{close} permette di chiudere un file, in questo modo il file
-descriptor ritorna disponibile; il suo prototipo è:
-\begin{prototype}{unistd.h}{int close(int fd)}
- Chiude il descrittore \param{fd}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, con \var{errno} che assume i valori:
+Una volta che l'accesso ad un file non sia più necessario la funzione di
+sistema \funcd{close} permette di ``\textsl{chiuderlo}'', in questo modo il
+file non sarà più accessibile ed il relativo file descriptor ritornerà
+disponibile; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int close(int fd)}
+\fdesc{Chiude un file.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EBADF}] \param{fd} non è un descrittore valido.
\item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}
- ed inoltre \errval{EIO}.}
-\end{prototype}
+ ed inoltre \errval{EIO} nel suo significato generico.}
+\end{funcproto}
-La chiusura di un file rilascia ogni blocco (il \textit{file locking}
-\itindex{file~locking} è trattato in sez.~\ref{sec:file_locking}) che il
-processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
-riferimento (di eventuali copie) ad un file aperto, tutte le risorse nella
-\itindex{file~table} \textit{file table} vengono rilasciate. Infine se il file
-descriptor era l'ultimo riferimento ad un file su disco quest'ultimo viene
-cancellato.
-
-Si ricordi che quando un processo termina anche tutti i suoi file descriptor
-vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
-esplicitamente \func{close}. In genere comunque chiudere un file senza
-controllarne lo stato di uscita è errore; infatti molti filesystem
-implementano la tecnica del \textit{write-behind}, per cui una \func{write}
-può avere successo anche se i dati non sono stati scritti, un eventuale errore
-di I/O allora può sfuggire, ma verrà riportato alla chiusura del file: per
-questo motivo non effettuare il controllo può portare ad una perdita di dati
-inavvertita.\footnote{in Linux questo comportamento è stato osservato con NFS
- e le quote su disco.}
+La funzione chiude il file descriptor \param{fd}, la chiusura rilascia ogni
+blocco (il \textit{file locking} \itindex{file~locking} è trattato in
+sez.~\ref{sec:file_locking}) che il processo poteva avere acquisito su di
+esso. Se \param{fd} è l'ultimo riferimento (di eventuali copie, vedi
+sez.~\ref{sec:file_sharing} e \ref{sec:file_dup}) ad un file aperto, tutte le
+risorse nella \itindex{file~table} \textit{file table} vengono
+rilasciate. Infine se il file descriptor era l'ultimo riferimento ad un file
+su disco quest'ultimo viene cancellato.
+
+Si ricordi che quando un processo termina tutti i suoi file descriptor vengono
+automaticamente chiusi, molti programmi sfruttano questa caratteristica e non
+usano esplicitamente \func{close}. In genere comunque chiudere un file senza
+controllare lo stato di uscita di \func{close} un è errore; molti filesystem
+infatti implementano la tecnica del cosiddetto \textit{write-behind}, per cui
+una \func{write} può avere successo anche se i dati non sono stati
+effettivamente scritti su disco. In questo caso un eventuale errore di I/O
+avvenuto in un secondo tempo potrebbe sfuggire, mentre verrebbe riportato alla
+chiusura esplicita del file. Per questo motivo non effettuare il controllo può
+portare ad una perdita di dati inavvertita.\footnote{in Linux questo
+ comportamento è stato osservato con NFS e le quote su disco.}
In ogni caso una \func{close} andata a buon fine non garantisce che i dati
siano stati effettivamente scritti su disco, perché il kernel può decidere di
Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
una \textsl{posizione corrente nel file} (il cosiddetto \textit{file offset},
-mantenuto nel campo \var{f\_pos} di \kstruct{file}) espressa da un numero intero
-positivo come numero di byte dall'inizio del file. Tutte le operazioni di
-lettura e scrittura avvengono a partire da questa posizione che viene
-automaticamente spostata in avanti del numero di byte letti o scritti.
-
-In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
-\const{O\_APPEND}) questa posizione viene impostata a zero all'apertura del
-file. È possibile impostarla ad un valore qualsiasi con la funzione
-\funcd{lseek}, il cui prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{unistd.h}
- \funcdecl{off\_t lseek(int fd, off\_t offset, int whence)}
- Imposta la posizione attuale nel file.
-
- \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:
+mantenuto nel campo \var{f\_pos} di \kstruct{file}) espressa da un numero
+intero positivo che esprime il numero di byte dall'inizio del file. Tutte le
+operazioni di lettura e scrittura avvengono a partire da questa posizione che
+viene automaticamente spostata in avanti del numero di byte letti o scritti.
+
+In genere, a meno di non avere richiesto la modalità \itindex{append~mode} di
+\textit{append} con \const{O\_APPEND}, questa posizione viene impostata a zero
+all'apertura del file. È possibile impostarla ad un valore qualsiasi con la
+funzione si sistema \funcd{lseek}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{unistd.h}
+\fdecl{off\_t lseek(int fd, off\_t offset, int whence)}
+\fdesc{Imposta la posizione sul file..}
+}
+
+{La funzione ritorna il valore della posizione sul file in caso di successo e
+ $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
\item[\errcode{EINVAL}] \param{whence} non è un valore valido.
\item[\errcode{EOVERFLOW}] \param{offset} non può essere rappresentato nel
tipo \type{off\_t}.
\end{errlist}
- ed inoltre \errval{EBADF}.}
-\end{functions}
+ ed inoltre \errval{EBADF} nel suo significato generico.}
+\end{funcproto}
-La nuova posizione è impostata usando il valore specificato da \param{offset},
-sommato al riferimento dato da \param{whence}; quest'ultimo può assumere i
-seguenti valori\footnote{per compatibilità con alcune vecchie notazioni
- questi valori possono essere rimpiazzati rispettivamente con 0, 1 e 2 o con
- \const{L\_SET}, \const{L\_INCR} e \const{L\_XTND}.}:
-\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SEEK\_SET}] si fa riferimento all'inizio del file: il valore
- (sempre positivo) di \param{offset} indica direttamente la nuova posizione
- corrente.
-\item[\const{SEEK\_CUR}] si fa riferimento alla posizione corrente del file:
- ad essa viene sommato \param{offset} (che può essere negativo e positivo)
- per ottenere la nuova posizione corrente.
-\item[\const{SEEK\_END}] si fa riferimento alla fine del file: alle dimensioni
- del file viene sommato \param{offset} (che può essere negativo e positivo)
- per ottenere la nuova posizione corrente.
-\end{basedescript}
+La funzione imposta la nuova posizione sul file usando il valore specificato
+da \param{offset}, che viene sommato al riferimento dato
+dall'argomento \param{whence}. Quest'ultimo deve essere indicato con una delle
+costanti riportate in tab.~\ref{tab:lseek_whence_values}.\footnote{per
+ compatibilità con alcune vecchie notazioni questi valori possono essere
+ rimpiazzati rispettivamente con 0, 1 e 2 o con \const{L\_SET},
+ \const{L\_INCR} e \const{L\_XTND}.}
-% TODO, trattare, SEEK_HOLE e SEEK_DATA, inclusi nel kernel 3.1, vedi
-% http://lwn.net/Articles/439623/
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{SEEK\_SET} & Si fa riferimento all'inizio del file: il valore, che
+ deve essere positivo, di \param{offset} indica
+ direttamente la nuova posizione corrente.\\
+ \const{SEEK\_CUR} & Si fa riferimento alla posizione corrente del file:
+ ad essa viene sommato \param{offset}, che può essere
+ negativo e positivo, per ottenere la nuova posizione
+ corrente.\\
+ \const{SEEK\_END} & Si fa riferimento alla fine del file: alle dimensioni
+ del file viene sommato \param{offset}, che può essere
+ negativo e positivo, per ottenere la nuova posizione
+ corrente.\\
+ \hline
+ \const{SEEK\_DATA}& Sposta la posizione nel file sull'inizio del primo
+ blocco di dati dopo un \textit{hole} che segue (o
+ coincide) con la posizione indicata da \param{offset}.\\
+ \const{SEEK\_HOLE}& Sposta la posizione sul file all'inizio del primo
+ \textit{hole} nel file che segue o inizia
+ con \param{offset}, oppure \param{offset} se questo è
+ all'interno di un \textit{hole} o alla fine del file
+ se non ci sono \textit{hole} dopo \param{offset}.\\
+ \hline
+ \end{tabular}
+ \caption{Possibili valori per l'argomento \param{whence} di \func{lseek}.}
+ \label{tab:lseek_whence_values}
+\end{table}
+% NOTE: per SEEK_HOLE e SEEK_DATA, inclusi nel kernel 3.1, vedi
+% http://lwn.net/Articles/439623/
+
Si tenga presente che la chiamata a \func{lseek} non causa nessun accesso al
-file, si limita a modificare la posizione corrente (cioè il valore
-\var{f\_pos} in \param{file}, vedi fig.~\ref{fig:file_proc_file}). Dato che
+file, si limita a modificare la posizione corrente (cioè il campo \var{f\_pos}
+della struttura \kstruct{file}, vedi fig.~\ref{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)}.
Infine si tenga presente che, come accennato in sez.~\ref{sec:file_file_size},
con \func{lseek} è possibile impostare una posizione anche oltre la corrente
-fine del file; ed in tal caso alla successiva scrittura il file sarà esteso a
-partire da detta posizione. In questo caso si ha quella che viene chiamata la
-creazione di un \index{file!\textit{hole}} \textsl{buco} nel file, accade cioè
-che nonostante la dimensione del file sia cresciuta in seguito alla scrittura
-effettuata, lo spazio vuoto fra la precedente fine del file ed la nuova parte
-scritta dopo lo spostamento, non corrisponda ad una allocazione effettiva di
-spazio su disco, che sarebbe inutile dato che quella zona è effettivamente
-vuota.
-
-Questa è una delle caratteristiche spcifiche della gestione dei file di un
+fine del file. In tal caso alla successiva scrittura il file sarà esteso a
+partire da detta posizione, ed in questo si ha quella che viene chiamata la
+creazione di un \index{file!\textit{hole}} \textsl{buco} nel file. Il nome
+deriva dal fatto che nonostante la dimensione del file sia cresciuta in
+seguito alla scrittura effettuata, lo spazio vuoto fra la precedente fine del
+file ed la nuova parte scritta dopo lo spostamento non corrisponde ad una
+allocazione effettiva di spazio su disco, che sarebbe inutile dato che quella
+zona è effettivamente vuota.
+
+Questa è una delle caratteristiche specifiche della gestione dei file di un
sistema unix-like, ed in questo caso si ha appunto quello che in gergo si
chiama un \index{file!\textit{hole}} \textit{hole} nel file e si dice che il
file in questione è uno \textit{sparse file}. In sostanza, se si ricorda la
effettivamente allocato, e viene registrata sull'\textit{inode} come le altre
proprietà del file. La dimensione viene aggiornata automaticamente quando si
estende un file scrivendoci, e viene riportata dal campo \var{st\_size} di una
-struttura \struct{stat} quando si effettua chiamata ad una delle funzioni
+struttura \struct{stat} quando si effettua la chiamata ad una delle funzioni
\texttt{*stat} viste in sez.~\ref{sec:file_stat}.
Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
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{funcproto}{
+\fhead{unistd.h}
+\fdecl{ssize\_t read(int fd, void * buf, size\_t count)}
+\fdesc{Legge i dati da un file.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \end{errlist}
+ ed inoltre
+ nel loro significato generico.}
+\end{funcproto}
+
\begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
Cerca di leggere \param{count} byte dal file \param{fd} al buffer
\errcode{EAGAIN}.} che indica soltanto che non essendoci al momento dati
disponibili occorre provare a ripetere la lettura in un secondo tempo.
-La funzione \func{read} è una delle system call fondamentali, esistenti fin
-dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix
- Specification}\footnote{questa funzione, e l'analoga \func{pwrite} sono
- state aggiunte nel kernel 2.1.60, il supporto nelle \acr{glibc}, compresa
- l'emulazione per i vecchi kernel che non hanno la system call, è stato
- aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
- delle librerie la funzione non è disponibile.} (quello che viene chiamato
-normalmente Unix98, vedi sez.~\ref{sec:intro_xopen}) è stata introdotta la
-definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
+La funzione \func{read} è una delle \textit{system call} fondamentali,
+esistenti fin dagli albori di Unix, ma nella seconda versione delle
+\textit{Single Unix Specification}\footnote{questa funzione, e l'analoga
+ \func{pwrite} sono state aggiunte nel kernel 2.1.60, il supporto nelle
+ \acr{glibc}, compresa l'emulazione per i vecchi kernel che non hanno la
+ \textit{system call}, è stato aggiunto con la versione 2.1, in versioni
+ precedenti sia del kernel che delle librerie la funzione non è disponibile.}
+(quello che viene chiamato normalmente Unix98, vedi
+sez.~\ref{sec:intro_xopen}) è stata introdotta la definizione di un'altra
+funzione di lettura, \funcd{pread}, il cui prototipo è:
\begin{prototype}{unistd.h}
{ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
più alla fine del file, e la successiva \func{write} sovrascriverà i dati del
secondo processo.
-Il problema è che usare due system call in successione non è un'operazione
-atomica; il problema è stato risolto introducendo la modalità
+Il problema è che usare due \textit{system call} in successione non è
+un'operazione atomica; il problema è stato risolto introducendo la modalità
\itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
alla fine del file prima di effettuare la scrittura, e poi estende il file.
-Tutto questo avviene all'interno di una singola system call (la \func{write})
-che non essendo interrompibile da un altro processo costituisce un'operazione
-atomica.
+Tutto questo avviene all'interno di una singola \textit{system call} (la
+\func{write}) che non essendo interrompibile da un altro processo costituisce
+un'operazione atomica.
Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
creare un \textsl{file di lock} \index{file!di lock}, bloccandosi se il file
\const{O\_CREAT} e \const{O\_EXCL}. In questo modo l'operazione di controllo
dell'esistenza del file (con relativa uscita dalla funzione con un errore) e
creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno
-di una singola system call (per i dettagli sull'uso di questa caratteristica
-si veda sez.~\ref{sec:ipc_file_lock}).
+di una singola \textit{system call} (per i dettagli sull'uso di questa
+caratteristica si veda sez.~\ref{sec:ipc_file_lock}).
\subsection{Le funzioni \func{sync} e \func{fsync}}
altre operazioni) usando un \itindsub{pathname}{relativo} \textit{pathname}
relativo ad una directory specificata.\footnote{l'introduzione è avvenuta su
proposta dello sviluppatore principale delle \acr{glibc} Urlich Drepper; le
- corrispondenti system call sono state inserite nel kernel ufficiale a
- partire dalla versione 2.6.16, in precedenza era disponibile una emulazione
- che, sia pure con prestazioni inferiori, funzionava facendo ricorso all'uso
- del filesystem \textit{proc} con l'apertura del file attraverso il
- riferimento a \textit{pathname} del tipo di
+ corrispondenti \textit{system call} sono state inserite nel kernel ufficiale
+ a partire dalla versione 2.6.16, in precedenza era disponibile una
+ emulazione che, sia pure con prestazioni inferiori, funzionava facendo
+ ricorso all'uso del filesystem \textit{proc} con l'apertura del file
+ attraverso il riferimento a \textit{pathname} del tipo di
\texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste funzioni non
siano presenti negli standard tradizionali esse sono state adottate da vari
Unix\footnote{oltre a Linux e Solaris sono presenti in vari BSD.} fino ad
La bufferizzazione è una delle caratteristiche principali dell'interfaccia
degli \textit{stream}; lo scopo è quello di ridurre al minimo il numero di
-system call (\func{read} o \func{write}) eseguite nelle operazioni di
+\textit{system call} (\func{read} o \func{write}) eseguite nelle operazioni di
input/output. Questa funzionalità è assicurata automaticamente dalla libreria,
ma costituisce anche uno degli aspetti più comunemente fraintesi, in
particolare per quello che riguarda l'aspetto della scrittura dei dati sul
valori diversi.} definito anch'esso nell'header \headfile{stdlib.h}.
Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
-libreria che si appoggiano a delle system call, esse non impostano
+libreria che si appoggiano a delle \textit{system call}, esse non impostano
direttamente la variabile \var{errno}, che mantiene il valore impostato dalla
-system call che ha riportato l'errore.
+\textit{system call} che ha riportato l'errore.
Siccome la condizione di end-of-file è anch'essa segnalata come errore, nasce
il problema di come distinguerla da un errore effettivo; basarsi solo sul
ai \textit{thread}, per questo le operazioni sui buffer effettuate dalle
funzioni di libreria durante la lettura e la scrittura di uno \textit{stream}
devono essere opportunamente protette (in quanto il sistema assicura
-l'atomicità solo per le system call). Questo viene fatto associando ad ogni
-\textit{stream} un opportuno blocco che deve essere implicitamente acquisito
-prima dell'esecuzione di qualunque operazione.
+l'atomicità solo per le \textit{system call}). Questo viene fatto associando
+ad ogni \textit{stream} un opportuno blocco che deve essere implicitamente
+acquisito prima dell'esecuzione di qualunque operazione.
Ci sono comunque situazioni in cui questo non basta, come quando un
\textit{thread} necessita di compiere più di una operazione sullo
% LocalWords: nell'header stdin shell stdout stderr error freopen flush line
% LocalWords: unbuffered buffered newline fully SVr fopen fdopen POSIX const
% LocalWords: char path int fildes NULL errno malloc fcntl fclose fflush tab
-% LocalWords: dup fifo socket append EXCL ccs STRING IRUSR IWUSR IRGRP IWGRP
+% LocalWords: dup fifo socket append EXCL ccs IRUSR IWUSR IRGRP IWGRP
% LocalWords: IROTH IWOTH umask fseek fsetpos rewind SEEK CUR EOF EBADF close
-% LocalWords: sync fcloseall SOURCE void stdlib of feof ferror clearerr l'I ws
+% LocalWords: sync fcloseall void stdlib of feof ferror clearerr ws
% LocalWords: unlocked fread fwrite size ptr nmemb nelem gcc padding point str
-% LocalWords: lock thread fgetc getc getchar dell'overhead altresì unsigned ap
-% LocalWords: getwc fgetwc getwchar wint wchar WEOF putc fputc putchar dell'I
+% LocalWords: lock thread fgetc getc getchar dell'overhead unsigned ap
+% LocalWords: getwc fgetwc getwchar wint wchar WEOF putc fputc putchar
% LocalWords: SVID getw putw parsing peeking ahead ungetc gets fgets string Di
% LocalWords: overflow Aleph stack fputs puts fgetws fputws getline ssize leak
% LocalWords: realloc value result argument memory getdelim delim printf short
% LocalWords: lseek ftell fgetpos fpos fseeko ftello fileno Solaris freadable
% LocalWords: fwritable ext freading fwriting buffering setvbuf BUFSIZ setbuf
% LocalWords: IONBF IOLBF IOFBF setbuffer setlinebuf flbf fbufsize flushlbf hh
-% LocalWords: fsync fpurge flockfile ftrylockfile funlockfile SAFE FUNCTIONS
-% LocalWords: locking fsetlocking type BYCALLER QUERY ll
-
-
-
-% LocalWords: descriptor system call cap like kernel sez l'inode inode VFS tab
-% LocalWords: process table struct files flags pos all'inode dentry fig shell
-% LocalWords: error POSIX STDIN FILENO STDOUT STDERR unistd read write lseek
-% LocalWords: close pathname sys fcntl int const char errno EEXIST CREAT EXCL
-% LocalWords: EISDIR ENOTDIR ENXIO NOBLOCK WRONLY fifo ENODEV ETXTBSY ELOOP of
-% LocalWords: NOFOLLOW EACCES ENAMETOOLONG ENOENT EROFS EFAULT ENOSPC ENOMEM
-% LocalWords: EMFILE ENFILE NFS lock race condition Denial Service DoS RDONLY
-% LocalWords: glibc RDWR NONBLOCK NOCTTY SHLOCK shared BSD EXLOCK TRUNC device
-% LocalWords: opendir LARGEFILE APPEND append NDELAY ASYNC l'I SIGIO SYNC SVr
-% LocalWords: DSYNC RSYNC filesystem DIRECT caching SGI IRIX dell'I FreeBSD fd
-% LocalWords: fork exec umask SOURCE creat filedes EBADF EINTR EIO locking off
-% LocalWords: behind sync flush shutdown whence ESPIPE socket EINVAL INCR XTND
-% LocalWords: SEEK CUR EPIPE ssize void buf size count EAGAIN EWOULDBLOCK log
-% LocalWords: Specification pwrite pread EFBIG SIGPIPE nell'inode dall'inode
-% LocalWords: CLOEXEC stat fsync cache update l'update bdflush Documentation
-% LocalWords: fdatasync fstat ext dup oldfd newfd DUPFD cmd long arg flock pid
-% LocalWords: SETFD GETFD GETFL SETFL GETLK SETLK SETLKW GETOWN group SIGURG
-% LocalWords: SETOWN GETSIG SETSIG sigaction SIGINFO siginfo SETLEASE lease is
-% LocalWords: truncate GETLEASE NOTIFY AND ACCMODE ioctl everything argp all'I
-% LocalWords: framebuffer request ENOTTY CDROM nell'header magic number openat
-% LocalWords: FIOCLEX FIONCLEX FIOASYNC FIONBIO NOATIME redirezione FIOSETOWN
-% LocalWords: FIOGETOWN FIONREAD mkdirat thread Solaris mkdir at Urlich proc
-% LocalWords: Drepper path dirfd faccessat unlinkat access fchmodat chmod Di
-% LocalWords: fchownat chown fstatat futimesat utimes linkat mknodat mknod uid
-% LocalWords: readlinkat readlink renameat rename symlinkat symlink unlink gid
-% LocalWords: mkfifoat mkfifo FDCWD dereferenziazione rmdir REMOVEDIR
-% LocalWords: epoll lsattr chattr FIOQSIZE ATFILE lutimes utimensat lchown
-% LocalWords: lstat owner FOLLOW
+% LocalWords: fsync fpurge flockfile ftrylockfile funlockfile
+% LocalWords: locking fsetlocking type Virtual operation
+% LocalWords: modification hole functions FSETSIG
+
+
+
%%% Local Variables:
%%% mode: latex
projects / gapil.git / commitdiff