Correzioni varie parte terza

diff --git a/filedir.tex b/filedir.tex
index 24f331be5c9c42493f15c7a1a92f05ec612fcd3f..7601b73f57706a6a64eb3bc977245b2a41a0cafe 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -4,11 +4,11 @@
 In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
 file e directory, iniziando dalle funzioni di libreria che si usano per
 copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che
 In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
 file e directory, iniziando dalle funzioni di libreria che si usano per
 copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che

-permette la manipolazione dei vari attributi di file e directory ed alla
-fine faremo una trattazione dettagliata su come è strutturato il sistema base
-di protezioni e controllo di accesso ai file e sulle funzioni che ne
-permettono la gestione. Tutto quello che riguarda invece la manipolazione del
-contenuto dei file è lasciato ai capitoli successivi.
+permette la manipolazione dei vari attributi di file e directory ed alla fine
+faremo una trattazione dettagliata su come è strutturato il sistema base di
+protezioni e controllo dell'accesso ai file e sulle funzioni che ne permettono
+la gestione. Tutto quello che riguarda invece la manipolazione del contenuto
+dei file è lasciato ai capitoli successivi.

 
 
 
 
 
 


@@ -20,7 +20,7 @@ direttamente dall'architettura del sistema; in questa sezione esamineremo le
 funzioni usate per manipolazione nel filesytem di file e directory, per la
 creazione di link simbolici e diretti, per la gestione e la lettura delle
 directory; il tutto mettendo in evidenza le conseguenze della struttura
 funzioni usate per manipolazione nel filesytem di file e directory, per la
 creazione di link simbolici e diretti, per la gestione e la lettura delle
 directory; il tutto mettendo in evidenza le conseguenze della struttura

-standard della gestione dei file in un sistema unix-like, già accennate al
+standard della gestione dei file in un sistema unix-like, introdotta nel

 capitolo precedente.
 
 
 capitolo precedente.
 
 


@@ -46,7 +46,8 @@ riferimento al suddetto inode.
 Questo significa che la realizzazione di un link è immediata in quanto uno
 stesso file può avere tanti nomi diversi allo stesso tempo, dati da
 altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
 Questo significa che la realizzazione di un link è immediata in quanto uno
 stesso file può avere tanti nomi diversi allo stesso tempo, dati da
 altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di

-questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
+questi nomi viene ad assumere una particolare preferenza o originalità
+rispetto agli altri.

 
 Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si
 suole chiamare questo tipo di associazione un collegamento diretto (o
 
 Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si
 suole chiamare questo tipo di associazione un collegamento diretto (o


@@ -90,9 +91,9 @@ meccanismo non 
 Windows). 
 
 La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
 Windows). 
 
 La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del

-filesystem, con l'eccezione delle directory. In alcuni versioni di unix solo
+filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo

 l'amministratore è in grado di creare un collegamento diretto ad un'altra
 l'amministratore è in grado di creare un collegamento diretto ad un'altra

-directory, questo viene fatto perché con una tale operazione è possibile
+directory: questo viene fatto perché con una tale operazione è possibile

 creare dei circoli nel filesystem (vedi l'esempio mostrato in
 \secref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi
 non sono in grado di gestire e la cui rimozione diventerebbe estremamente
 creare dei circoli nel filesystem (vedi l'esempio mostrato in
 \secref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi
 non sono in grado di gestire e la cui rimozione diventerebbe estremamente


@@ -142,9 +143,10 @@ restrizioni 
 
 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
 della nome dalla directory e l'incremento/decremento del numero di riferimenti
 
 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
 della nome dalla directory e l'incremento/decremento del numero di riferimenti

-nell'inode deve essere una operazione atomica (si veda
-\secref{sec:proc_atom_oper}), per questo entrambe queste funzioni sono
-realizzate tramite una singola system call.
+nell'inode devono essere effettuati in maniera atomica (si veda
+\secref{sec:proc_atom_oper}) senza possibili interruzioni fra le due
+operazioni, per questo entrambe queste funzioni sono realizzate tramite una
+singola system call.

 
 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
 
 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link


@@ -223,7 +225,7 @@ esiste, non deve essere una directory (altrimenti si ha l'errore
 \macro{EISDIR}). Nel caso \var{newpath} indichi un file esistente questo viene
 cancellato e rimpiazzato (atomicamente).
 
 \macro{EISDIR}). Nel caso \var{newpath} indichi un file esistente questo viene
 cancellato e rimpiazzato (atomicamente).
 

-Se \var{oldpath} è una directory allora \var{newpath} se esiste deve essere
+Se \var{oldpath} è una directory allora \var{newpath}, se esiste, deve essere

 una directory vuota, altrimenti si avranno gli errori \macro{ENOTDIR} (se non
 è una directory) o \macro{ENOTEMPTY} (se non è vuota). Chiaramente
 \var{newpath} non può contenere \var{oldpath} altrimenti si avrà un errore
 una directory vuota, altrimenti si avranno gli errori \macro{ENOTDIR} (se non
 è una directory) o \macro{ENOTEMPTY} (se non è vuota). Chiaramente
 \var{newpath} non può contenere \var{oldpath} altrimenti si avrà un errore


@@ -233,9 +235,9 @@ Se \var{oldpath} si riferisce a un link simbolico questo sar
 \var{newpath} è un link simbolico verrà cancellato come qualunque altro file.
 Infine qualora \var{oldpath} e \var{newpath} siano due nomi dello stesso file
 lo standard POSIX prevede che la funzione non dia errore, e non faccia nulla,
 \var{newpath} è un link simbolico verrà cancellato come qualunque altro file.
 Infine qualora \var{oldpath} e \var{newpath} siano due nomi dello stesso file
 lo standard POSIX prevede che la funzione non dia errore, e non faccia nulla,

-lasciando entrambi i nomi; Linux segue questo standard, anche se come fatto
-notare dal manuale delle glibc, il comportamento più ragionevole sarebbe
-quello di cancellare \var{oldpath}.
+lasciando entrambi i nomi; Linux segue questo standard, anche se, come fatto
+notare dal manuale delle \textit{glibc}, il comportamento più ragionevole
+sarebbe quello di cancellare \var{oldpath}.

 
 Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di
 \func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
 
 Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di
 \func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non


@@ -246,7 +248,7 @@ eseguita.
 
 In ogni caso se \var{newpath} esiste e l'operazione fallisce per un qualche
 motivo (come un crash del kernel), \func{rename} garantisce di lasciare
 
 In ogni caso se \var{newpath} esiste e l'operazione fallisce per un qualche
 motivo (come un crash del kernel), \func{rename} garantisce di lasciare

-presente una istanza di \var{newpath}, tuttavia nella sovrascrittura potrà
+presente una istanza di \var{newpath}. Tuttavia nella sovrascrittura potrà

 esistere una finestra in cui sia \var{oldpath} che \var{newpath} fanno
 riferimento allo stesso file.
 
 esistere una finestra in cui sia \var{oldpath} che \var{newpath} fanno
 riferimento allo stesso file.
 


@@ -256,16 +258,16 @@ riferimento allo stesso file.
 
 Come abbiamo visto in \secref{sec:file_link} la funzione \func{link} crea
 riferimenti agli inodes, pertanto può funzionare soltanto per file che
 
 Come abbiamo visto in \secref{sec:file_link} la funzione \func{link} crea
 riferimenti agli inodes, pertanto può funzionare soltanto per file che

-risiedono sullo stesso filesystem e solo per un filesystem di tipo unix.
+risiedono sullo stesso filesystem e solo per un filesystem di tipo Unix.

 Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto
 ad una directory.
 
 Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto
 ad una directory.
 

-Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
+Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di

 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
 come avviene in altri sistemi operativi, dei file speciali che contengono il
 semplicemente il riferimento ad un altro file (o directory). In questo modo è
 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
 come avviene in altri sistemi operativi, dei file speciali che contengono il
 semplicemente il riferimento ad un altro file (o directory). In questo modo è

-possibile effettuare link anche attraverso filesystem diversi, a file posti in
-filesystem che non supportano i link diretti, a delle directory, e anche a
+possibile effettuare link anche attraverso filesystem diversi, a file posti
+in filesystem che non supportano i link diretti, a delle directory, ed anche a

 file che non esistono ancora.
 
 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
 file che non esistono ancora.
 
 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali


@@ -298,9 +300,8 @@ specificato. La funzione che permette di creare un nuovo link simbolico 
 Si tenga presente che la funzione non effettua nessun controllo sull'esistenza
 di un file di nome \param{oldpath}, ma si limita ad inserire quella stringa
 nel link simbolico. Pertanto un link simbolico può anche riferirsi ad un file
 Si tenga presente che la funzione non effettua nessun controllo sull'esistenza
 di un file di nome \param{oldpath}, ma si limita ad inserire quella stringa
 nel link simbolico. Pertanto un link simbolico può anche riferirsi ad un file

-che non esiste: quello che viene chiamato un \textit{dangling link},
-letteralmente \textsl{link ciondolante}.
-
+che non esiste: in questo caso si ha quello che viene chiamato un
+\textit{dangling link}, letteralmente un \textsl{link ciondolante}.

 
 Come accennato i link simbolici sono risolti automaticamente dal kernel
 all'invocazione delle varie system call; in \ntab\ si è riportato un elenco
 
 Come accennato i link simbolici sono risolti automaticamente dal kernel
 all'invocazione delle varie system call; in \ntab\ si è riportato un elenco


@@ -362,12 +363,8 @@ la funzione \func{readlink}, il cui prototipo 
     \var{buff} o -1 per un errore, nel qual caso la variabile
     \var{errno} viene settata a:
   \begin{errlist}
     \var{buff} o -1 per un errore, nel qual caso la variabile
     \var{errno} viene settata a:
   \begin{errlist}

-  \item[\macro{EINVAL}] \var{file} non è un link simbolico o \var{size} non è
-    positiva. 
-  \item[\macro{EROFS}] La directory su cui si vuole inserire il nuovo link è
-    su un filesystem montato in sola lettura.
-  \item[\macro{ENOSPC}] La directory o il filesystem in cui si vuole creare il
-    link è piena e non c'è ulteriore spazio disponibile.
+  \item[\macro{EINVAL}] \param{path} non è un link simbolico o \param{size}
+    non è positiva.

   \end{errlist}
   ed inoltre \macro{ENOTDIR}, \macro{ENAMETOOLONG}, \macro{ENOENT},
   \macro{EACCES}, \macro{ELOOP}, \macro{EIO}, \macro{EFAULT} e
   \end{errlist}
   ed inoltre \macro{ENOTDIR}, \macro{ENAMETOOLONG}, \macro{ENOENT},
   \macro{EACCES}, \macro{ELOOP}, \macro{EIO}, \macro{EFAULT} e


@@ -382,7 +379,7 @@ stringa con un carattere nullo e la tronca alla dimensione specificata da
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering

-  \includegraphics[width=5cm]{img/link_loop}
+  \includegraphics[width=7cm]{img/link_loop}

   \caption{Esempio di loop nel filesystem creato con un link simbolico.}
   \label{fig:file_link_loop}
 \end{figure}
   \caption{Esempio di loop nel filesystem creato con un link simbolico.}
   \label{fig:file_link_loop}
 \end{figure}


@@ -392,27 +389,28 @@ cosiddetti \textit{loop}. La situazione 
 la struttura della directory \file{/boot}. Come si vede si è creato al suo
 interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
   tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
 la struttura della directory \file{/boot}. Come si vede si è creato al suo
 interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
   tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un

-  bootloader estremamente avanzato in grado di accedere direttamente
-  attraverso vari filesystem al file da lanciare come sistema operativo) di
-  vedere i file in questa directory, che è montata su una partizione separata
-  (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
-  visti dal sistema operativo.}. 
+  bootloader in grado di leggere direttamente da vari filesystem il file da
+  lanciare come sistema operativo) di vedere i file in questa directory con lo
+  stesso path con cui verrebbero visti dal sistema operativo, anche se essi si
+  trovano, come è solito, su una partizione separata (e che \cmd{grub}
+  vedrebbe come radice).}.

 
 Questo può causare problemi per tutti quei programmi che effettuano la
 scansione di una directory senza tener conto dei link simbolici, ad esempio se
 
 Questo può causare problemi per tutti quei programmi che effettuano la
 scansione di una directory senza tener conto dei link simbolici, ad esempio se

-lanciassimo un comando del tipo \cmd{grep -r linux *}, il loop nella directory
-porterebbe il comando ad esaminare \file{/boot}, \file{/boot/boot},
+lanciassimo un comando del tipo \code{grep -r linux *}, il loop nella
+directory porterebbe il comando ad esaminare \file{/boot}, \file{/boot/boot},

 \file{/boot/boot/boot} e così via.
 
 Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
 un pathname possano essere seguiti un numero limitato di link simbolici, il
 \file{/boot/boot/boot} e così via.
 
 Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
 un pathname possano essere seguiti un numero limitato di link simbolici, il

-cui valore limite è specificato dalla costante \macro{MAXSYMLINKS}; qualora
+cui valore limite è specificato dalla costante \macro{MAXSYMLINKS}. Qualora

 questo limite venga superato viene generato un errore ed \var{errno} viene
 settata al valore \macro{ELOOP}.
 
 questo limite venga superato viene generato un errore ed \var{errno} viene
 settata al valore \macro{ELOOP}.
 

-Un punto da tenere sempre presente è il fatto che un link simbolico può fare
-riferimento anche ad un file che non esiste; ad esempio possiamo creare un
-file temporaneo nella nostra directory con un link del tipo:
+Un punto da tenere sempre presente è che, come abbiamo accennato, un link
+simbolico può fare riferimento anche ad un file che non esiste; ad esempio
+possiamo creare un file temporaneo nella nostra directory con un link del
+tipo:

 \begin{verbatim}
 $ ln -s /tmp/tmp_file temporaneo
 \end{verbatim}%$
 \begin{verbatim}
 $ ln -s /tmp/tmp_file temporaneo
 \end{verbatim}%$


@@ -424,8 +422,8 @@ quanto aprendo in scrittura \file{temporaneo} verr
 $ cat temporaneo
 cat: temporaneo: No such file or directory
 \end{verbatim}%$
 $ cat temporaneo
 cat: temporaneo: No such file or directory
 \end{verbatim}%$

-con un errore che può sembrare sbagliato, dato che invece \cmd{ls} ci
-mostrerebbe l'esistenza di \file{temporaneo}.
+con un errore che può sembrare sbagliato, dato che una ispezione con \cmd{ls}
+ci mostrerebbe invece l'esistenza di \file{temporaneo}.

 
 
 \subsection{La creazione e la cancellazione delle directory} 
 
 
 \subsection{La creazione e la cancellazione delle directory} 


@@ -460,7 +458,7 @@ accedere ai tipi usati da queste funzioni si deve includere il file
   \macro{ENOENT}, \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP},
   \macro{EROFS}.}
 \end{prototype}
   \macro{ENOENT}, \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP},
   \macro{EROFS}.}
 \end{prototype}

- 
+

 La funzione crea una nuova directory vuota (che contiene solo le due voci
 standard \file{.} e \file{..}). I permessi di accesso (vedi la trattazione in
 \secref{sec:file_access_control}) specificati da \var{mode} (i cui possibili
 La funzione crea una nuova directory vuota (che contiene solo le due voci
 standard \file{.} e \file{..}). I permessi di accesso (vedi la trattazione in
 \secref{sec:file_access_control}) specificati da \var{mode} (i cui possibili


@@ -512,7 +510,7 @@ Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in
 degli altri tipi di file, come i file di dispositivo e le fifo (i socket sono
 un caso a parte, che vedremo in \secref{cha:socket_intro}). 
 
 degli altri tipi di file, come i file di dispositivo e le fifo (i socket sono
 un caso a parte, che vedremo in \secref{cha:socket_intro}). 
 

-La manipolazione delle caratteristiche di questi filee e la loro cancellazione
+La manipolazione delle caratteristiche di questi file e la loro cancellazione

 può essere effettuata con le stesse funzioni che operano sui file normali; ma
 quando li si devono creare sono necessarie delle funzioni apposite. La prima
 di queste funzioni è \func{mknod}, il suo prototipo è:
 può essere effettuata con le stesse funzioni che operano sui file normali; ma
 quando li si devono creare sono necessarie delle funzioni apposite. La prima
 di queste funzioni è \func{mknod}, il suo prototipo è:


@@ -542,9 +540,9 @@ di queste funzioni 
 La funzione permette di creare un file speciale, ma si può usare anche per
 creare file normali e fifo; l'argomento \param{mode} specifica il tipo di file
 che si vuole creare ed i relativi permessi, secondo i valori riportati in
 La funzione permette di creare un file speciale, ma si può usare anche per
 creare file normali e fifo; l'argomento \param{mode} specifica il tipo di file
 che si vuole creare ed i relativi permessi, secondo i valori riportati in

-\tabref{tab:file_mode_flags}, che vanno combinato come OR binario. I permessi
-sono comunque modificati nella maniera usuale dal valore di \var{umask} (si
-veda \secref{sec:file_umask}.
+\tabref{tab:file_mode_flags}, che vanno combinati con un OR binario. I
+permessi sono comunque modificati nella maniera usuale dal valore di
+\var{umask} (si veda \secref{sec:file_umask}).

 
 Per il tipo di file può essere specificato solo uno fra: \macro{S\_IFREG} per
 un file normale (che sarà creato vuoto), \macro{S\_IFBLK} per un device a
 
 Per il tipo di file può essere specificato solo uno fra: \macro{S\_IFREG} per
 un file normale (che sarà creato vuoto), \macro{S\_IFBLK} per un device a


@@ -560,7 +558,7 @@ usando questa funzione; ma in Linux\footnote{la funzione non 
 agli utenti normali.
 
 I nuovi inode creati con \func{mknod} apparterranno al proprietario e al
 agli utenti normali.
 
 I nuovi inode creati con \func{mknod} apparterranno al proprietario e al

-gruppo del processo che li creati, a meno che non si sia attivato il bit
+gruppo del processo che li ha creati, a meno che non si sia attivato il bit

 \acr{sgid} per la directory o sia stata attivata la semantica BSD per il
 filesystem (si veda \secref{sec:file_ownership}) in cui si va a creare
 l'inode.
 \acr{sgid} per la directory o sia stata attivata la semantica BSD per il
 filesystem (si veda \secref{sec:file_ownership}) in cui si va a creare
 l'inode.


@@ -576,7 +574,7 @@ Per creare una fifo (un file speciale, su cui torneremo in dettaglio in
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} assumerà i valori \macro{EACCESS},
     \macro{EEXIST}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOSPC},
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} assumerà i valori \macro{EACCESS},
     \macro{EEXIST}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOSPC},

-    \macro{ENOTDIR} e\macro{EROFS}.}
+    \macro{ENOTDIR} e \macro{EROFS}.}

 \end{functions}
 \noindent come per \func{mknod} il file \param{pathname} non deve esistere
 (neanche come link simbolico); al solito i permessi specificati da
 \end{functions}
 \noindent come per \func{mknod} il file \param{pathname} non deve esistere
 (neanche come link simbolico); al solito i permessi specificati da


@@ -671,8 +669,8 @@ pathname ricavato risalendo all'indietro l'albero della directory, si
 perderebbe traccia di ogni passaggio attraverso eventuali link simbolici.
 
 Per cambiare la directory di lavoro corrente si può usare la funzione
 perderebbe traccia di ogni passaggio attraverso eventuali link simbolici.
 
 Per cambiare la directory di lavoro corrente si può usare la funzione

-\func{chdir} (omonima dell'analogo comando di shell) il cui nome sta appunto
-per \textit{change directory}), il suo prototipo è:
+\func{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta
+appunto per \textit{change directory}, il suo prototipo è:

 \begin{prototype}{unistd.h}{int chdir(const char *pathname)} 
   Cambia la directory di lavoro corrente in \param{pathname}.
   
 \begin{prototype}{unistd.h}{int chdir(const char *pathname)} 
   Cambia la directory di lavoro corrente in \param{pathname}.
   


@@ -711,7 +709,7 @@ specificata da \param{fd}.
 \subsection{I file temporanei}
 \label{sec:file_temp_file}
 
 \subsection{I file temporanei}
 \label{sec:file_temp_file}
 

-In molte occasioni è utile poter creare dei file temporanei; benchè la cosa
+In molte occasioni è utile poter creare dei file temporanei; benché la cosa

 sembri semplice in realtà il problema è più sottile di quanto non appaia a
 prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
 creare il file dopo aver controllato che questo non esista, nel momento fra il
 sembri semplice in realtà il problema è più sottile di quanto non appaia a
 prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
 creare il file dopo aver controllato che questo non esista, nel momento fra il


@@ -750,12 +748,12 @@ esplicitamente, il suo prototipo 
   \macro{ENOMEM} qualora fallisca l'allocazione della stringa.}
 \end{prototype}
 
   \macro{ENOMEM} qualora fallisca l'allocazione della stringa.}
 \end{prototype}
 

-La funzione alloca con \code{malloc} la stringa in cui resituisce il nome, per
-cui è sempre rientrante, occorre però ricordarsi di disallocare il puntatore
-che restituisce.  L'argomento \param{pfx} specifica un prefisso di massimo 5
-caratteri per il nome provvisorio. La funzione assegna come directory per il
-file temporaneo (verificando che esista e sia accessibili), la prima valida
-delle seguenti:
+La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
+per cui è sempre rientrante, occorre però ricordarsi di disallocare il
+puntatore che restituisce.  L'argomento \param{pfx} specifica un prefisso di
+massimo 5 caratteri per il nome provvisorio. La funzione assegna come
+directory per il file temporaneo (verificando che esista e sia accessibili),
+la prima valida delle seguenti:

 \begin{itemize*}
 \item La variabile di ambiente \macro{TMPNAME} (non ha effetto se non è
   definita o se il programma chiamante è \acr{suid} o \acr{sgid}, vedi
 \begin{itemize*}
 \item La variabile di ambiente \macro{TMPNAME} (non ha effetto se non è
   definita o se il programma chiamante è \acr{suid} o \acr{sgid}, vedi


@@ -788,8 +786,8 @@ POSIX definisce la funzione \func{tempfile}, il cui prototipo 
     ed inoltre \macro{EFAULT}, \macro{EMFILE}, \macro{ENFILE}, \macro{ENOSPC},
     \macro{EROFS} e \macro{EACCESS}.}
 \end{prototype}
     ed inoltre \macro{EFAULT}, \macro{EMFILE}, \macro{ENFILE}, \macro{ENOSPC},
     \macro{EROFS} e \macro{EACCESS}.}
 \end{prototype}

-\noindent restituisce direttamente uno stream già aperto (in modalità
-\code{r+b}, si veda \secref{sec:file_fopen}) e pronto per l'uso che viene
+\noindent essa restituisce direttamente uno stream già aperto (in modalità
+\code{r+b}, si veda \secref{sec:file_fopen}) e pronto per l'uso, che viene

 automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo
 standard non specifica in quale directory verrà aperto il file, ma \acr{glibc}
 prima tentano con \macro{P\_tmpdir} e poi con \file{/tmp}. Questa funzione è
 automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo
 standard non specifica in quale directory verrà aperto il file, ma \acr{glibc}
 prima tentano con \macro{P\_tmpdir} e poi con \file{/tmp}. Questa funzione è


@@ -817,9 +815,9 @@ funzione non si pu
 alle possibili \textit{race condition} date per \func{tmpnam} continuano a
 valere; inoltre in alcune vecchie implementazioni il valore di usato per
 sostituire le \code{XXXXXX} viene formato con il \acr{pid} del processo più
 alle possibili \textit{race condition} date per \func{tmpnam} continuano a
 valere; inoltre in alcune vecchie implementazioni il valore di usato per
 sostituire le \code{XXXXXX} viene formato con il \acr{pid} del processo più

-una lettera, il che mette a disposizione solo 26 possibilità, e rende il nome
-temporaneo facile da indovinare. Per tutti questi motivi la funzione è
-deprecata e non dovrebbe mai essere usata.
+una lettera, il che mette a disposizione solo 26 possibilità diverse per il
+nome del file, e rende il nome temporaneo facile da indovinare. Per tutti
+questi motivi la funzione è deprecata e non dovrebbe mai essere usata.

 
 
 
 
 
 


@@ -838,9 +836,9 @@ prototipo 
       contenuto di \param{template} è indefinito.
     \end{errlist}}
 \end{prototype}
       contenuto di \param{template} è indefinito.
     \end{errlist}}
 \end{prototype}

-\noindent come per \func{mktemp} \param{template} non può essere una stringa
-costante. La funzione apre un file in lettura/scrittura con la funzione
-\func{open}, usando l'opzione \macro{O\_EXCL} (si veda
+\noindent come per \func{mktemp} anche in questo caso \param{template} non può
+essere una stringa costante. La funzione apre un file in lettura/scrittura con
+la funzione \func{open}, usando l'opzione \macro{O\_EXCL} (si veda

 \secref{sec:file_open}), in questo modo al ritorno della funzione si ha la
 certezza di essere i soli utenti del file. I permessi sono settati al valore
 \code{0600}\footnote{questo è vero a partire dalle \acr{glibc} 2.0.7, le
 \secref{sec:file_open}), in questo modo al ritorno della funzione si ha la
 certezza di essere i soli utenti del file. I permessi sono settati al valore
 \code{0600}\footnote{questo è vero a partire dalle \acr{glibc} 2.0.7, le


@@ -913,12 +911,15 @@ queste funzioni sono i seguenti:
     \macro{ELOOP}, \macro{EFAULT}, \macro{EACCESS}, \macro{ENOMEM},
     \macro{ENAMETOOLONG}.}
 \end{functions}
     \macro{ELOOP}, \macro{EFAULT}, \macro{EACCESS}, \macro{ENOMEM},
     \macro{ENAMETOOLONG}.}
 \end{functions}

+\noindent il loro comportamento è identico, solo che operano rispettivamente
+su un file, su un link simbolico e su un file descriptor.

 
 

-La struttura \var{stat} è definita nell'header \file{sys/stat.h} e in
-generale dipende dall'implementazione, la versione usata da Linux è mostrata
-in \nfig, così come riportata dalla man page (in realtà la definizione
-effettivamente usata nel kernel dipende dall'architettura e ha altri campi
-riservati per estensioni come tempi più precisi, o per il padding dei campi).
+La struttura \var{stat} usata da queste funzioni è definita nell'header
+\file{sys/stat.h} e in generale dipende dall'implementazione, la versione
+usata da Linux è mostrata in \nfig, così come riportata dalla man page di
+\func{stat} (in realtà la definizione effettivamente usata nel kernel dipende
+dall'architettura e ha altri campi riservati per estensioni come tempi più
+precisi, o per il padding dei campi).

 
 \begin{figure}[!htb]
   \footnotesize
 
 \begin{figure}[!htb]
   \footnotesize


@@ -956,15 +957,16 @@ del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
 \subsection{I tipi di file}
 \label{sec:file_types}
 
 \subsection{I tipi di file}
 \label{sec:file_types}
 

-Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e
-alle directory esistono vari altri oggetti che possono stare su un filesystem;
-il tipo di file è ritornato dalla \func{stat} nel campo \var{st\_mode}
-(che è quello che contiene anche le informazioni relative ai permessi).
+Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e alle
+directory esistono vari altri oggetti che possono stare su un filesystem.  Il
+tipo di file è ritornato dalla \func{stat} come maschera binaria nel campo
+\var{st\_mode} (che che contiene anche le informazioni relative ai permessi).

 
 Dato che il valore numerico può variare a seconda delle implementazioni, lo
 standard POSIX definisce un insieme di macro per verificare il tipo di files,
 
 Dato che il valore numerico può variare a seconda delle implementazioni, lo
 standard POSIX definisce un insieme di macro per verificare il tipo di files,

-queste vengono usate anche da Linux che supporta pure le estensioni per link
-simbolici e socket definite da BSD, l'elenco completo di tutte le macro è
+queste vengono usate anche da Linux che supporta pure le estensioni allo
+standard per i link simbolici e i socket definite da BSD; l'elenco completo
+delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è

 riportato in \ntab.
 \begin{table}[htb]
   \centering
 riportato in \ntab.
 \begin{table}[htb]
   \centering


@@ -987,10 +989,17 @@ riportato in \ntab.
   \label{tab:file_type_macro}
 \end{table}
 
   \label{tab:file_type_macro}
 \end{table}
 

-Oltre a queste macro è possibile usare direttamente il valore di
-\var{st\_mode} per ricavare il significato dei vari bit in esso memorizzati,
-per questo sempre in \file{sys/stat.h} sono definiti i flag riportati in
-\ntab:
+Oltre alle macro di \tabref{tab:file_type_macro} è possibile usare
+direttamente il valore di \var{st\_mode} per ricavare il tipo di file
+controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
+\file{sys/stat.h} sono definite le costanti numeriche riportate in \ntab.
+
+Il primo valore dell'elenco di \secref{tab:file_mode_flags} è la maschera
+binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
+file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
+possono essere usati per effettuare la selezione sul tipo di file voluto, con
+una opportuna combinazione.
+

 \begin{table}[htb]
   \centering
   \footnotesize
 \begin{table}[htb]
   \centering
   \footnotesize


@@ -1033,11 +1042,9 @@ per questo sempre in \file{sys/stat.h} sono definiti i flag riportati in
   \label{tab:file_mode_flags}
 \end{table}
 
   \label{tab:file_mode_flags}
 \end{table}
 

-Il primo valore definisce la maschera dei bit usati nei quali viene
-memorizzato il tipo di files, mentre gli altri possono essere usati per
-effettuare delle selezioni sul tipo di file voluto, combinando opportunamente
-i vari flag; ad esempio se si volesse controllare se un file è una directory o
-un file ordinario si potrebbe definire la condizione:
+Ad esempio se si volesse impostare una condizione che permetta di controllare
+se un file è una directory o un file ordinario si potrebbe definire la macro
+di preprocessore:

 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 #define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG))
 \end{lstlisting}
 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 #define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG))
 \end{lstlisting}


@@ -1045,12 +1052,12 @@ in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
 poi si effettua il confronto con la combinazione di tipi scelta.
 
 
 poi si effettua il confronto con la combinazione di tipi scelta.
 
 

-\subsection{La dimensione dei file}
+\subsection{Le dimensioni dei file}

 \label{sec:file_file_size}
 
 \label{sec:file_file_size}
 

-Il membro \var{st\_size} contiene la dimensione del file in byte (se il file
-è un file normale, nel caso di un link simbolico al dimensione è quella del
-pathname che contiene). 
+Il membro \var{st\_size} contiene la dimensione del file in byte (se il file è
+un file normale, nel caso di un link simbolico la dimensione è quella del
+pathname che contiene).

 
 Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
 byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
 
 Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
 byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per


@@ -1060,12 +1067,12 @@ dimensione inferiore sarebbe inefficiente.
 
 Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
 che corrisponda all'occupazione dello spazio su disco per via della possibile
 
 Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
 che corrisponda all'occupazione dello spazio su disco per via della possibile

-esistenza dei cosiddetti \textsl{buchi} (detti normalmente \textit{holes}) che
+esistenza dei cosiddetti \textit{holes} (letteralmente \textsl{buchi}) che

 si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
 una \func{lseek} (vedi \secref{sec:file_lseek}) oltre la sua conclusione
 corrente.
 
 si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
 una \func{lseek} (vedi \secref{sec:file_lseek}) oltre la sua conclusione
 corrente.
 

-In tal caso si avranno differenti risultati a seconda del modi in cui si
+In questo caso si avranno risultati differenti a seconda del modo in cui si

 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
 numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
 legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
 numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
 legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal


@@ -1079,7 +1086,8 @@ presenti al di l
 
 Un file può sempre essere troncato a zero aprendolo con il flag
 \macro{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
 
 Un file può sempre essere troncato a zero aprendolo con il flag
 \macro{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra

-dimensione si possono usare le due funzioni:
+dimensione si possono usare le due funzioni \func{truncate} e
+\func{ftruncate}, i cui prototipi sono:

 \begin{functions}
   \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
     length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad
 \begin{functions}
   \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
     length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad


@@ -1130,7 +1138,7 @@ riportato un esempio delle funzioni che effettuano cambiamenti su di essi.
   \begin{tabular}[c]{|c|l|l|c|}
     \hline
     \textbf{Membro} & \textbf{Significato} & \textbf{Funzione} 
   \begin{tabular}[c]{|c|l|l|c|}
     \hline
     \textbf{Membro} & \textbf{Significato} & \textbf{Funzione} 

-    & \textbf{Opzione} \\
+    & \textbf{Opzione di \cmd{ls}} \\

     \hline
     \hline
     \var{st\_atime}& ultimo accesso ai dati del file &\func{read}, 
     \hline
     \hline
     \var{st\_atime}& ultimo accesso ai dati del file &\func{read}, 


@@ -1187,18 +1195,20 @@ quest'ultimo.
   \begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
     \hline
     \multicolumn{1}{|p{3cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} &
   \begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
     \hline
     \multicolumn{1}{|p{3cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} &

-    \multicolumn{3}{|p{3cm}|}{\centering{File o directory di riferimento}}&
-    \multicolumn{3}{|p{3cm}|}{\centering{Directory genitrice del riferimento}} 
+    \multicolumn{3}{|p{3.6cm}|}{\centering{
+        \textbf{File o directory del riferimento}}}&
+    \multicolumn{3}{|p{3.6cm}|}{\centering{
+        \textbf{Directory contenente il riferimento}}} 

     &\multicolumn{1}{|p{3.6cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\
     \cline{2-7}
     \cline{2-7}
     \multicolumn{1}{|p{3cm}|}{} 
     &\multicolumn{1}{|p{3.6cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\
     \cline{2-7}
     \cline{2-7}
     \multicolumn{1}{|p{3cm}|}{} 

-    &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
-    &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
-    &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
-    &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
-    &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
-    &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
+    &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(a)}}}
+    &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(m)}}}
+    &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(c)}}}
+    &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(a)}}}
+    &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(m)}}}
+    &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(c)}}}

     &\multicolumn{1}{|p{3cm}|}{} \\
     \hline
     \hline
     &\multicolumn{1}{|p{3cm}|}{} \\
     \hline
     \hline


@@ -1229,9 +1239,9 @@ quest'ultimo.
     \func{read}
     &$\bullet$&         &         &         &         &         & \\
     \func{remove}
     \func{read}
     &$\bullet$&         &         &         &         &         & \\
     \func{remove}

-    &         &         &$\bullet$&         &$\bullet$&$\bullet$& using 
+    &         &         &$\bullet$&         &$\bullet$&$\bullet$& se esegue 

     \func{unlink}\\    \func{remove}
     \func{unlink}\\    \func{remove}

-    &         &         &         &         &$\bullet$&$\bullet$& using 
+    &         &         &         &         &$\bullet$&$\bullet$& se esegue 

     \func{rmdir}\\ \func{rename}
     &         &         &$\bullet$&         &$\bullet$&$\bullet$& per entrambi
     gli argomenti\\ \func{rmdir}
     \func{rmdir}\\ \func{rename}
     &         &         &$\bullet$&         &$\bullet$&$\bullet$& per entrambi
     gli argomenti\\ \func{rmdir}


@@ -1253,7 +1263,7 @@ quest'ultimo.
 \end{table}
 
 Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
 \end{table}
 
 Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di

-creazione del file, usato in molti altri sistemi operativi, ma che in unix non
+creazione del file, usato in molti altri sistemi operativi, ma che in Unix non

 esiste. Per questo motivo quando si copia un file, a meno di preservare
 esplicitamente i tempi (ad esempio con l'opzione \cmd{-p} di \cmd{cp}) esso
 avrà sempre il tempo corrente come data di ultima modifica.
 esiste. Per questo motivo quando si copia un file, a meno di preservare
 esplicitamente i tempi (ad esempio con l'opzione \cmd{-p} di \cmd{cp}) esso
 avrà sempre il tempo corrente come data di ultima modifica.


@@ -1316,50 +1326,50 @@ le funzioni usate per gestirne i vari aspetti.
 \subsection{I permessi per l'accesso ai file}
 \label{sec:file_perm_overview}
 
 \subsection{I permessi per l'accesso ai file}
 \label{sec:file_perm_overview}
 

-Il controllo di accesso ai file in unix segue un modello abbastanza semplice
+Il controllo di accesso ai file in Unix segue un modello abbastanza semplice

 (ma adatto alla gran parte delle esigenze) in cui si dividono i permessi su
 tre livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem
 (ma adatto alla gran parte delle esigenze) in cui si dividono i permessi su
 tre livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem

-di tipo unix, e non è detto che sia applicabile a un filesystem
+di tipo Unix, e non è detto che sia applicabile a un filesystem

 qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
   per il quale i permessi vengono assegnati in maniera fissa con un opzione in
 qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
   per il quale i permessi vengono assegnati in maniera fissa con un opzione in

-  fase di montaggio}.  Esistono inoltre estensioni che permettono di
+  fase di montaggio.}.  Esistono inoltre estensioni che permettono di

 implementare le ACL (\textit{Access Control List}) che sono un meccanismo di
 controllo di accesso molto più sofisticato.
 
 implementare le ACL (\textit{Access Control List}) che sono un meccanismo di
 controllo di accesso molto più sofisticato.
 

-Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
-\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
-identificatori di utenti e gruppi (\acr{uid} e \acr{gid}). Questi valori
+Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
+cosiddetto \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo
+degli identificatori di utenti e gruppi (\acr{uid} e \acr{gid}). Questi valori

 sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
 della struttura \var{stat} (si veda \secref{sec:file_stat}). Ad ogni file
 sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
 della struttura \var{stat} (si veda \secref{sec:file_stat}). Ad ogni file

-viene inoltre associato un insieme di permessi che sono divisi in tre classi,
+viene inoltre associato un insieme di permessi che sono divisi in tre livelli,

 e cioè attribuiti rispettivamente all'utente proprietario del file, a un
 qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
 altri utenti.
 
 I permessi, così come vengono presi dai comandi e dalle routine di sistema,
 e cioè attribuiti rispettivamente all'utente proprietario del file, a un
 qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
 altri utenti.
 
 I permessi, così come vengono presi dai comandi e dalle routine di sistema,

-sono espressi da un numero di 12 bit; di questi i nove meno significativi sono
+sono espressi da un numero a 12 bit; di questi i nove meno significativi sono

 usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
 esecuzione (indicati nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e
 \cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti
 usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
 esecuzione (indicati nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e
 \cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti

-gli altri.  I restanti tre bit (\acr{suid}, \acr{sgid}, e
-\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
-su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e
-\secref{sec:file_sticky}).
-
-Anche i permessi, come tutte le altre informazioni generali, sono tenuti per
-ciascun file nell'inode; in particolare essi sono contenuti in alcuni bit
-del campo \var{st\_mode} della struttura letta da \func{stat} (di nuovo si veda
-\secref{sec:file_stat} per i dettagli).
-
-In genere ci si riferisce a questo raggruppamento dei permessi usando le
-lettere \cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o}
-(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
-insieme si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente
-questa distinzione dato che in certi casi, mutuando la terminologia in uso nel
-VMS, si parla dei permessi base come di permessi per \textit{owner},
-\textit{group} ed \textit{all}, le cui iniziali possono dar luogo a confusione.
-Le costanti che permettono di accedere al valore numerico di questi bit nel
-campo \var{st\_mode} sono riportate in \ntab.
+gli altri.  I restanti tre bit (\acr{suid}, \acr{sgid}, e \textsl{sticky})
+sono usati per indicare alcune caratteristiche più complesse del meccanismo
+del controllo di accesso su cui torneremo in seguito (in
+\secref{sec:file_suid_sgid} e \secref{sec:file_sticky}).
+
+Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
+memorizzati nell'inode; in particolare essi sono contenuti in alcuni bit del
+campo \var{st\_mode} della struttura \func{stat} (si veda
+\figref{fig:file_stat_struct}).
+
+In genere ci si riferisce ai tre livelli dei permessi usando le lettere
+\cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o} (per
+\textit{other}), inoltre se si vuole indicare tutti i raggruppamenti insieme
+si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente questa
+distinzione dato che in certi casi, mutuando la terminologia in uso nel VMS,
+si parla dei permessi base come di permessi per \textit{owner}, \textit{group}
+ed \textit{all}, le cui iniziali possono dar luogo a confusione.  Le costanti
+che permettono di accedere al valore numerico di questi bit nel campo
+\var{st\_mode} sono riportate in \ntab.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering

diff --git a/fileintro.tex b/fileintro.tex
index 010add3be64c39094d05bed03863814924d91641..40d8e2575d262890ff440b6f165c95eb1f563537 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -176,7 +176,8 @@ Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
 dati e che non c'è nessun supporto del sistema per le estensioni come parte
 del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
 i nomi dei file, ad esempio il codice C normalmente si mette in file con
 dati e che non c'è nessun supporto del sistema per le estensioni come parte
 del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
 i nomi dei file, ad esempio il codice C normalmente si mette in file con

-l'estensione \file{.c}, ma questa è, appunto, solo una convenzione.
+l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
+universale, solo una convenzione.

 
 
 
 
 
 


@@ -296,23 +297,23 @@ POSIX.1 dei sistemi Unix, ed 
 Per capire fino in fondo le proprietà di file e directory in un sistema
 unix-like ed il comportamento delle relative funzioni di manipolazione occorre
 una breve introduzione al funzionamento gestione dei file da parte del kernel
 Per capire fino in fondo le proprietà di file e directory in un sistema
 unix-like ed il comportamento delle relative funzioni di manipolazione occorre
 una breve introduzione al funzionamento gestione dei file da parte del kernel

-e sugli oggetti su cui è basato un filesystem di tipo unix. In particolare
-occorre tenere presente dov'è che si situa la divisione fondamentale fra
-kernel space e user space che tracciavamo al \capref{cha:intro_unix}.
+e sugli oggetti su cui è basato un filesystem. In particolare occorre tenere
+presente dov'è che si situa la divisione fondamentale fra kernel space e user
+space che tracciavamo al \capref{cha:intro_unix}.

 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo

-prima le caratteristiche generali di un filesystem Unix, per poi trattare in
-maniera un po' più dettagliata il filesystem standard di Linux, l'\acr{ext2}.
+prima le caratteristiche generali di un filesystem di un sistema unix-like,
+per poi trattare in maniera un po' più dettagliata il filesystem standard di
+Linux, l'\acr{ext2}.

 
 

+% in particolare si riprenderà, approfondendolo sul piano dell'uso nelle
+% funzioni di libreria, il concetto di \textit{inode} di cui abbiamo brevemente
+% accennato le caratteristiche (dal lato dell'implementazione nel kernel) in
+% \secref{sec:file_vfs}.

 
 

-% in particolare si riprenderà, approfondendolo sul piano
-% dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui
-% abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione
-% nel kernel) in \secref{sec:file_vfs}.

 
 

-
-\subsection{Il \textit{virtual filesystem} di Linux}
+\subsection{Il \textit{Virtual Filesystem} di Linux}

 \label{sec:file_vfs}
 
 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
 \label{sec:file_vfs}
 
 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i


@@ -322,13 +323,14 @@ maniera un po' pi
 % \textit{inode}, \textit{dentry}, \textit{dcache}.
 
 In Linux il concetto di \textit{everything is a file} è stato implementato
 % \textit{inode}, \textit{dentry}, \textit{dcache}.
 
 In Linux il concetto di \textit{everything is a file} è stato implementato

-attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è
-l'interfaccia che il kernel rende disponibile ai programmi in user space
-attraverso la quale vengono manipolati i file; esso provvede un livello di
-indirezione che permette di collegare le operazioni di manipolazione sui file
-alle operazioni di I/O e gestisce l'organizzazione di questi ultimi nei vari
-modi in cui diversi filesystem la effettuano, permettendo la coesistenza
-di filesystem differenti all'interno dello stesso albero delle directory
+attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno
+strato intermedio che il kernel usa per accedere ai più svariati filesystem
+mantenendo la stessa interfaccia per i programmi in user space. Esso provvede
+un livello di indirezione che permette di collegare le operazioni di
+manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
+queste ultime nei vari modi in cui diversi filesystem le effettuano,
+permettendo la coesistenza di filesystem differenti all'interno dello stesso
+albero delle directory.

 
 Quando un processo esegue una system call che opera su un file il kernel
 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
 
 Quando un processo esegue una system call che opera su un file il kernel
 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le


@@ -361,17 +363,17 @@ In questo modo quando viene effettuata la richiesta di montare un nuovo disco
 (o qualunque altro \textit{block device} che può contenere un filesystem), il
 VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
 (o qualunque altro \textit{block device} che può contenere un filesystem), il
 VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco

-il superblock (vedi \ref{sec:file_ext2}), inizializzare tutte le
-variabili interne e restituire uno speciale descrittore dei filesystem montati
-al VFS; attraverso quest'ultimo diventa possibile accedere alle routine
-specifiche per l'uso di quel filesystem.
+il superblock (vedi \secref{sec:file_ext2}), inizializzare tutte le variabili
+interne e restituire uno speciale descrittore dei filesystem montati al VFS;
+attraverso quest'ultimo diventa possibile accedere alle routine specifiche per
+l'uso di quel filesystem.

 
 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
 una apposita struttura che contiene vari dati come le informazioni comuni ad
 ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
 puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
 
 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
 una apposita struttura che contiene vari dati come le informazioni comuni ad
 ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
 puntatori alle funzioni del kernel relative al filesystem. Il VFS può così

-usare le funzioni contenute nel filesystem descriptor per accedere alle routine
-specifiche di quel filesystem.
+usare le funzioni contenute nel \textit{filesystem descriptor} per accedere
+alle routine specifiche di quel filesystem.

 
 Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
 
 Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni


@@ -386,28 +388,28 @@ file gi
 \subsection{Il funzionamento del VFS}
 \label{sec:file_vfs_work}
 
 \subsection{Il funzionamento del VFS}
 \label{sec:file_vfs_work}
 

-La funzione più fondamentale implementata dal VFS è la system call
-\func{open} che permette di aprire un file. Dato un pathname viene eseguita
-una ricerca dentro la \textit{directory entry cache} (in breve
-\textit{dcache}), una tabella di hash che contiene tutte le \textit{directory
-  entry} (in breve \textit{dentry}) che permette di associare in maniera
-rapida ed efficiente il pathname a una specifica dentry.
+La funzione più importante implementata dal VFS è la system call \func{open}
+che permette di aprire un file. Dato un pathname viene eseguita una ricerca
+dentro la \textit{directory entry cache} (in breve \textit{dcache}), una
+tabella che contiene tutte le \textit{directory entry} (in breve
+\textit{dentry}) che permette di associare in maniera rapida ed efficiente il
+pathname a una specifica \textit{dentry}.

 
 Una singola \textit{dentry} contiene in genere il puntatore ad un
 \textit{inode}; quest'ultimo è la struttura base che sta sul disco e che
 identifica un singolo oggetto del VFS sia esso un file ordinario, una
 directory, un link simbolico, una FIFO, un file di dispositivo, o una
 
 Una singola \textit{dentry} contiene in genere il puntatore ad un
 \textit{inode}; quest'ultimo è la struttura base che sta sul disco e che
 identifica un singolo oggetto del VFS sia esso un file ordinario, una
 directory, un link simbolico, una FIFO, un file di dispositivo, o una

-qualsiasi altra cosa che possa essere rappresentata dal VFS (sui tipi di
-``file'' possibili torneremo in seguito). A ciascuno di essi è associata pure
-una struttura che sta in memoria, e che oltre alle informazioni sullo
-specifico file contiene pure il riferimento alle funzioni (i \textsl{metodi})
-da usare per poterlo manipolare.
+qualsiasi altra cosa che possa essere rappresentata dal VFS (i tipi di
+``file'' riportati in \tabref{tab:file_file_types}). A ciascuno di essi è
+associata pure una struttura che sta in memoria, e che, oltre alle
+informazioni sullo specifico file, contiene anche il riferimento alle funzioni
+(i \textsl{metodi} del VFS) da usare per poterlo manipolare.

 
 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
 
 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,

-vengono usate per motivi di velocità, gli inode invece stanno su disco e
-vengono copiati in memoria quando serve, ed ogni cambiamento viene copiato
-all'indietro sul disco, gli inode che stanno in memoria sono inode del VFS ed
-è ad essi che puntano le singole \textit{dentry}.
+vengono usate per motivi di velocità, gli \textit{inode} invece stanno su
+disco e vengono copiati in memoria quando serve, ed ogni cambiamento viene
+copiato all'indietro sul disco, gli inode che stanno in memoria sono inode del
+VFS ed è ad essi che puntano le singole \textit{dentry}.

 
 La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
 l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
 
 La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
 l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è


@@ -421,9 +423,9 @@ della directory che contiene il file; questo viene installato nelle relative
 strutture in memoria quando si effettua il montaggio lo specifico filesystem
 su cui l'inode va a vivere.
 
 strutture in memoria quando si effettua il montaggio lo specifico filesystem
 su cui l'inode va a vivere.
 

-Una volta che il VFS ha a disposizione la dentry (ed il relativo inode)
-diventa possibile accedere alle varie operazioni sul file come la
-\func{open} per aprire il file o la \func{stat} per leggere i dati
+Una volta che il VFS ha a disposizione la \textit{dentry} (ed il relativo
+\textit{inode}) diventa possibile accedere alle varie operazioni sul file come
+la \func{open} per aprire il file o la \func{stat} per leggere i dati

 dell'inode e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
 dell'inode e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di


@@ -464,44 +466,45 @@ operazioni previste dal kernel 
   \label{tab:file_file_operations}
 \end{table}
 
   \label{tab:file_file_operations}
 \end{table}
 

-In questo modo per ciascun file diventano utilizzabili una serie di operazioni
-(non è dette che tutte siano disponibili), che costituiscono l'interfaccia
-astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad
+In questo modo per ciascun file diventano possibili una serie di operazioni
+(non è detto che tutte siano disponibili), che costituiscono l'interfaccia
+astratta del VFS.  Qualora se ne voglia eseguire una il kernel andrà ad

 utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
 utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo

-di file in questione. 
+di file in questione.

 
 

-Così sarà possibile scrivere sulla porta seriale come su un file di dati
-normale; ovviamente certe operazioni (nel caso della seriale ad esempio la
-\code{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
-diversi filesystem (come quelli usati da Windows o MacOs) è immediato e
-(relativamente) trasparente per l'utente ed il programmatore.
+In questo modo è possibile scrivere allo stesso modo sulla porta seriale come
+su un file di dati normale; ovviamente certe operazioni (nel caso della
+seriale ad esempio la \code{seek}) non saranno disponibili, però con questo
+sistema l'utilizzo di diversi filesystem (come quelli usati da Windows o
+MacOs) è immediato e (relativamente) trasparente per l'utente ed il
+programmatore.

 
 
 
 

-\subsection{Il funzionamento di un filesystem unix}
+\subsection{Il funzionamento di un filesystem Unix}

 \label{sec:file_filesystem}
 
 \label{sec:file_filesystem}
 

-Come già accennato in \secref{sec:file_organization} Linux (ed ogni unix
-in generale) organizza i dati che tiene su disco attraverso l'uso di un
+Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema
+unix-like) organizza i dati che tiene su disco attraverso l'uso di un

 filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
 quella di poter supportare grazie al VFS una enorme quantità di filesystem
 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
 filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
 quella di poter supportare grazie al VFS una enorme quantità di filesystem
 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità

-proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
-daremo una descrizione a grandi linee che si adatta alle caratteristiche
-comuni di un qualunque filesystem standard unix.
+proprie.  Per questo per il momento non entreremo nei dettagli di un
+filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
+alle caratteristiche comuni di qualunque filesystem di sistema unix-like.

 
 

-Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem; la strutturazione tipica
+Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
+partizione può contenere un filesystem. La strutturazione tipica

 dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
 alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
 in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
 di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
 dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
 alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
 in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
 di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica

-comune di tutti i filesystem unix, indipendentemente da come poi viene
+comune di tutti i filesystem per Unix, indipendentemente da come poi viene

 strutturata nei dettagli questa informazione, prevedere una divisione fra la
 lista degli inodes e lo spazio a disposizione per i dati e le directory.
 
 \begin{figure}[htb]
   \centering
 strutturata nei dettagli questa informazione, prevedere una divisione fra la
 lista degli inodes e lo spazio a disposizione per i dati e le directory.
 
 \begin{figure}[htb]
   \centering

-  \includegraphics[width=9cm]{img/disk_struct}
+  \includegraphics[width=12cm]{img/disk_struct}

   \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
   \label{fig:file_disk_filesys}
 \end{figure}
   \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
   \label{fig:file_disk_filesys}
 \end{figure}


@@ -514,15 +517,16 @@ esemplificare la situazione con uno schema come quello esposto in \nfig.
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering

-  \includegraphics[width=11cm]{img/filesys_struct}
+  \includegraphics[width=12cm]{img/filesys_struct}

   \caption{Strutturazione dei dati all'interno di un filesystem}
   \label{fig:file_filesys_detail}
 \end{figure}
 
   \caption{Strutturazione dei dati all'interno di un filesystem}
   \label{fig:file_filesys_detail}
 \end{figure}
 

-Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
-cui è bene porre attenzione in quanto sono fondamentali per capire il
-funzionamento delle funzioni che manipolano i file e le directory su cui
-torneremo in seguito; in particolare è opportuno ricordare sempre che:
+Da \curfig\ si evidenziano alcune delle caratteristiche di base di un
+filesystem, sulle quali è bene porre attenzione visto che sono fondamentali
+per capire il funzionamento delle funzioni che manipolano i file e le
+directory che tratteremo nel prossimo capitolo; in particolare è opportuno
+ricordare sempre che:

 
 \begin{enumerate}
   
 
 \begin{enumerate}
   


@@ -535,8 +539,8 @@ torneremo in seguito; in particolare 
   (traduzione approssimata dell'inglese \textit{directory entry}, che non
   useremo anche per evitare confusione con le \textit{dentry} del kernel di
   cui si parlava in \secref{sec:file_vfs}).
   (traduzione approssimata dell'inglese \textit{directory entry}, che non
   useremo anche per evitare confusione con le \textit{dentry} del kernel di
   cui si parlava in \secref{sec:file_vfs}).

-  
-\item Come mostrato in \curfig si possono avere più voci che puntano allo
+
+\item Come mostrato in \curfig\ si possono avere più voci che puntano allo

   stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
   numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
   solo quando questo contatore si annulla i dati del file vengono
   stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
   numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
   solo quando questo contatore si annulla i dati del file vengono


@@ -544,13 +548,13 @@ torneremo in seguito; in particolare 
   file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
   file, ma si limita a eliminare la relativa voce da una directory e
   decrementare il numero di riferimenti nell'\textit{inode}.
   file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
   file, ma si limita a eliminare la relativa voce da una directory e
   decrementare il numero di riferimenti nell'\textit{inode}.

-  
+

 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
   nello stesso filesystem e non ci può essere una directory che contiene
   riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
   l'uso del comando \cmd{ln} (che crea una nuova voce per un file
   esistente, con la funzione \func{link}) al filesystem corrente.
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
   nello stesso filesystem e non ci può essere una directory che contiene
   riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
   l'uso del comando \cmd{ln} (che crea una nuova voce per un file
   esistente, con la funzione \func{link}) al filesystem corrente.

-  
+

 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
   del file non deve essere spostato, viene semplicemente creata una nuova voce
   per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
   del file non deve essere spostato, viene semplicemente creata una nuova voce
   per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità


@@ -559,15 +563,15 @@ torneremo in seguito; in particolare 
 
 \end{enumerate}
 
 
 \end{enumerate}
 

-Infine è bene avere presente che essendo file pure loro, esiste un numero di
-riferimenti anche per le directory; per cui se ad esempio a partire dalla
-situazione mostrata in \curfig\ creiamo una nuova directory \file{img} nella
-directory \file{gapil}: avremo una situazione come quella in \nfig, dove per
-chiarezza abbiamo aggiunto dei numeri di inode.
+Infine è bene avere presente che, essendo file pure loro, esiste un numero di
+riferimenti anche per le directory; per cui se a partire dalla situazione
+mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
+\file{gapil}: avremo una situazione come quella in \nfig, dove per chiarezza
+abbiamo aggiunto dei numeri di inode.

 
 \begin{figure}[htb]
   \centering 
 
 \begin{figure}[htb]
   \centering 

-  \includegraphics[width=11cm]{img/dir_links}
+  \includegraphics[width=12cm]{img/dir_links}

   \caption{Organizzazione dei link per le directory}
   \label{fig:file_dirs_link}
 \end{figure}
   \caption{Organizzazione dei link per le directory}
   \label{fig:file_dirs_link}
 \end{figure}


@@ -586,12 +590,11 @@ adesso sar
 
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le

-caratteristiche di un filesystem standard unix, è in grado di gestire
-filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
-4~Tb. 
+caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di
+file lunghi (256 caratteri, estendibili a 1012), una dimensione fino a 4~Tb.

 
 

-Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni
-che non sono presenti sugli altri filesystem unix, le cui principali sono le
+Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni che
+non sono presenti sugli altri filesystem Unix, le cui principali sono le

 seguenti:
 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del
 seguenti:
 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del


@@ -620,7 +623,7 @@ seguenti:
   log).
 \end{itemize}
 
   log).
 \end{itemize}
 

-La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD,
+La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD:

 un filesystem è composto da un insieme di blocchi, la struttura generale è
 quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
 è divisa in gruppi di blocchi.
 un filesystem è composto da un insieme di blocchi, la struttura generale è
 quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
 è divisa in gruppi di blocchi.