%% 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",
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
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
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.
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
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
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
\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
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
projects / gapil.git / blobdiff