Versione finale del client ECHO su TCP, con esempio di uso della funzione

[gapil.git] / fileunix.tex

diff --git a/fileunix.tex b/fileunix.tex
index b23698a799fef0888f696ab8eed0df03cfe31ef2..6f9334df6dbf7e9fe4610bdb76afa858af1ba646 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -1,6 +1,6 @@
 %% fileunix.tex
 %%
 %% 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",
 %% 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.
 
 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
 
 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}. \\
     \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.\\
     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}).}
 
   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
 
 \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
 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
 
 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:
 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
 \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
 \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
 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
 
 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,
   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.
   \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. 
   
   \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}
     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
 
 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
 
 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
 
 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}
 
 
 \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)}
 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
 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
 
 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
 
 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
 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.
 
 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
 \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
 
 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}
 \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
 \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.
     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
   \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}
 
   \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
 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