X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=b90371d12638692cdb3339204181f01921ce92a4;hp=9b4025ec5606dcc71bfb89e66bd2d6addf3d4be0;hb=520fa6e7cd289a93a0955f3f91848ebd5b424250;hpb=9aad56ecd71e4f36e09f001cdd30b2106beec5c4

diff --git a/filedir.tex b/filedir.tex
index 9b4025e..b90371d 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -1,6 +1,6 @@
 %% filedir.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",
@@ -254,7 +254,7 @@ nello stesso filesystem) si usa invece la funzione \funcd{rename},\footnote{la
     sistema (come mount point).
   \item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
     \param{oldpath} o più in generale si è cercato di creare una directory come
-    sottodirectory di se stessa.
+    sotto-directory di se stessa.
   \item[\errcode{ENOTDIR}] Uno dei componenti dei pathname non è una directory
     o \param{oldpath} è una directory e \param{newpath} esiste e non è una
     directory.
@@ -319,12 +319,15 @@ 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
-al kernel (analogamente a quanto avviene per le directory) per cui per alcune
-funzioni di libreria (come \func{open} o \func{stat}) dare come parametro un
-link simbolico comporta l'applicazione della funzione al file da esso
-specificato. La funzione che permette di creare un nuovo link simbolico è
-\funcd{symlink}; il suo prototipo è:
+Il sistema funziona in quanto i link simbolici sono riconosciuti come tali dal
+kernel\footnote{è uno dei diversi tipi di file visti in
+  \tabref{tab:file_file_types}, contrassegnato come tale nell'inode, e
+  riconoscibile dal valore del campo \var{st\_mode} della struttura
+  \struct{stat} (vedi \secref{sec:file_stat}).}  per cui alcune funzioni di
+libreria (come \func{open} o \func{stat}) quando ricevono come argomento un
+link simbolico vengono automaticamente applicate al file da esso specificato.
+La funzione che permette di creare un nuovo link simbolico è \funcd{symlink},
+ed il suo prototipo è:
 \begin{prototype}{unistd.h}
   {int symlink(const char *oldpath, const char *newpath)} 
   Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
@@ -396,8 +399,8 @@ direttamente sul suo contenuto.
 Si noti che non si è specificato il comportamento delle funzioni che operano
 con i file descriptor, in quanto la risoluzione del link simbolico viene in
 genere effettuata dalla funzione che restituisce il file descriptor
-(normalmente la \func{open}) e tutte le operazioni seguenti fanno riferimento
-solo a quest'ultimo.
+(normalmente la \func{open}, vedi \secref{sec:file_open}) e tutte le
+operazioni seguenti fanno riferimento solo a quest'ultimo.
 
 Dato che, come indicato in \tabref{tab:file_symb_effect}, funzioni come la
 \func{open} seguono i link simbolici, occorrono funzioni apposite per accedere
@@ -438,12 +441,13 @@ Un caso comune che si pu
 cosiddetti \textit{loop}. La situazione è illustrata in
 \figref{fig:file_link_loop}, che riporta 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 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).}
+punta di nuovo a \file{/boot}.\footnote{il loop mostrato in
+  \figref{fig:file_link_loop} è un usato per poter permettere a \cmd{grub} (un
+  bootloader in grado di leggere direttamente da vari filesystem il file da
+  lanciare come sistema operativo) di vedere i file contenuti nella directory
+  \file{/boot} con lo stesso pathname con cui verrebbero visti dal sistema
+  operativo, anche se essi si trovano, come accade spesso, su una partizione
+  separata (che \cmd{grub}, all'avvio, vede 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
@@ -515,7 +519,7 @@ per creare una directory 
 \end{functions}
 
 La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
-standard \file{.} e \file{..}, con il nome indicato dall'argomento
+standard (\file{.} e \file{..}), con il nome indicato dall'argomento
 \param{dirname}. Il nome può essere indicato sia come pathname assoluto che
 relativo.
 
@@ -536,7 +540,7 @@ prototipo 
   \begin{errlist}
   \item[\errcode{EPERM}] Il filesystem non supporta la cancellazione di
     directory, oppure la directory che contiene \param{dirname} ha lo sticky
-    bit impostato e l'userid effettivo del processo non corrisponde al
+    bit impostato e l'user-ID effettivo del processo non corrisponde al
     proprietario della directory.
   \item[\errcode{EACCES}] Non c'è il permesso di scrittura per la directory
     che contiene la directory che si vuole cancellare, o non c'è il permesso
@@ -593,7 +597,7 @@ di queste funzioni 
     il filesystem su cui si è cercato di creare \func{pathname} non supporta
     l'operazione.
   \item[\errcode{EINVAL}] Il valore di \param{mode} non indica un file, una
-    fifo o un dipositivo.
+    fifo o un dispositivo.
   \item[\errcode{EEXIST}] \param{pathname} esiste già o è un link simbolico.
   \end{errlist}
   ed inoltre anche \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
@@ -642,32 +646,43 @@ Per creare una fifo (un file speciale, su cui torneremo in dettaglio in
     \errval{EEXIST}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOSPC},
     \errval{ENOTDIR} e \errval{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
-\param{mode} vengono modificati dal valore di \var{umask}.
+
+La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come
+per \func{mknod} il file \param{pathname} non deve esistere (neanche come link
+simbolico); al solito i permessi specificati da \param{mode} vengono
+modificati dal valore di \var{umask}.
 
 
 
 \subsection{Accesso alle directory}
 \label{sec:file_dir_read}
 
-Benché le directory siano oggetti del filesystem come tutti gli altri non ha
-senso aprirle come fossero dei file di dati. Inoltre si 
-
- Può però essere utile poterne
-leggere il contenuto ad esempio per fare la lista dei file che esse contengono
-o ricerche sui medesimi. Solo il kernel può scrivere direttamente il contenuto
-di una directory (onde evitare inconsistenze all'interno del filesystem), i
-processi devono creare i file usando le apposite funzioni.
-
-Per accedere al contenuto delle directory si usano i cosiddetti
-\textit{directory streams} (chiamati così per l'analogia con i file stream di
-\capref{cha:files_std_interface}); la funzione \funcd{opendir} apre uno di
-questi stream, il suo prototipo è:
+Benché le directory alla fine non siano altro che dei file che contengono
+delle liste di nomi ed inode, per il ruolo che rivestono nella struttura del
+sistema, non possono essere trattate come dei normali file di dati. Ad
+esempio, onde evitare inconsistenze all'interno del filesystem, solo il kernel
+può scrivere il contenuto di una directory, e non può essere un processo a
+inserirvi direttamente delle voci con le usuali funzioni di scrittura. 
+
+Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
+kernel, sono molte le situazioni in cui i processi necessitano di poterne
+leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo
+in \secref{sec:file_open} che è possibile aprire una directory come se fosse
+un file, anche se solo in sola lettura) in generale il formato con cui esse
+sono scritte può dipendere dal tipo di filesystem, tanto che, come riportato
+in \tabref{tab:file_file_operations}, il VFS del kernel prevede una apposita
+funzione per la lettura delle directory.
+
+Tutto questo si riflette nello standard POSIX\footnote{le funzioni sono
+  previste pure in BSD e SVID.} che ha introdotto una apposita interfaccia per
+la lettura delle directory, basata sui cosiddetti \textit{directory stream}
+(chiamati così per l'analogia con i file stream dell'interfaccia standard di
+\capref{cha:files_std_interface}). La prima funzione di questa interfaccia è
+\funcd{opendir}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   
-  \funcdecl{DIR * opendir(const char *name)} 
+  \funcdecl{DIR * opendir(const char *dirname)} 
   
   Apre un \textit{directory stream}.
   
@@ -677,16 +692,17 @@ questi stream, il suo prototipo 
     \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}.}
 \end{functions}
 
-La funzione apre un \textit{directory stream} per la directory indicata da
-\param{name}, ritornando il puntatore allo stesso, e posizionandosi sulla
-prima voce della directory. 
+La funzione apre un \textit{directory stream} per la directory
+\param{dirname}, ritornando il puntatore ad un oggetto di tipo \type{DIR} (che
+è il tipo opaco\index{tipo!opaco} usato dalle librerie per gestire i
+\textit{directory stream}) da usare per tutte le operazioni successive, la
+funzione inoltre posiziona lo stream sulla prima voce contenuta nella
+directory.
 
-Dato che le directory sono comunque dei file, in alcuni casi può essere utile
-conoscere il file descriptor sottostante un \textit{directory stream}, ad
-esempio per utilizzarlo con la funzione \func{fchdir} per cambiare la
-directory di lavoro (vedi \secref{sec:file_work_dir}) a quella relativa allo
-stream che si è aperto. A questo scopo si può usare la funzione \funcd{dirfd},
-il cui prototipo è:
+Dato che le directory sono comunque dei file, in alcuni casi può servire
+conoscere il \textit{file descriptor} associato ad un \textit{directory
+  stream}, a questo scopo si può usare la funzione \funcd{dirfd}, il cui
+prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   
@@ -698,32 +714,80 @@ il cui prototipo 
     caso di successo e -1 in caso di errore.}
 \end{functions}
 
-La funzione\footnote{questa funzione è una estensione di BSD introdotta con
-  BSD 4.3-Reno; è presente in Linux con le libc5 (a partire dalla versione
-  5.1.2) e con le \acr{glibc}.} restituisce il file descriptor associato al
-\textit{directory stream} \param{dir}, essa è disponibile solo definendo
-\macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE}.
-
-
+La funzione\footnote{questa funzione è una estensione di BSD non presente in
+  POSIX, introdotta con BSD 4.3-Reno; è presente in Linux con le libc5 (a
+  partire dalla versione 5.1.2) e con le \acr{glibc}.} restituisce il file
+descriptor associato al \textit{directory stream} \param{dir}, essa è
+disponibile solo definendo \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE}. Di
+solito si utilizza questa funzione in abbinamento alla funzione \func{fchdir}
+per cambiare la directory di lavoro (vedi \secref{sec:file_work_dir}) a quella
+relativa allo stream che si sta esaminando.
+
+La lettura di una voce della directory viene effettuata attraverso la funzione
+\funcd{readdir}; il suo prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} \headdecl{dirent.h} 
+  
+  \funcdecl{struct dirent *readdir(DIR *dir)}
+  
+  Legge una voce dal \textit{directory stream}.
+  
+  \bodydesc{La funzione restituisce il puntatore alla struttura contenente i
+    dati in caso di successo e \val{NULL} altrimenti, in caso di descrittore
+    non valido \var{errno} assumerà il valore \errval{EBADF}, il valore
+    \val{NULL} viene restituito anche quando si raggiunge la fine dello
+    stream.}
+\end{functions}
 
-La funzione \func{readdir} legge il contenuto della directory, i cui elementi
-sono le \textit{directory entry} (da distinguersi da quelle della cache di cui
-parlavamo in \secref{sec:file_vfs}) in un'opportuna struttura \struct{dirent}
-definita in \figref{fig:file_dirent_struct}.
+La funzione legge la voce corrente nella directory, posizionandosi sulla voce
+successiva.  I dati vengono memorizzati in una struttura \struct{dirent} (la
+cui definizione\footnote{la definizione è quella usata a Linux, che si trova
+  nel file \file{/usr/include/bits/dirent.h}, essa non contempla la presenza
+  del campo \var{d\_namlen} che indica la lunghezza del nome del file (ed
+  infatti la macro \macro{\_DIRENT\_HAVE\_D\_NAMLEN} non è definita).}  è
+riportata in \figref{fig:file_dirent_struct}). La funzione restituisce il
+puntatore alla struttura; si tenga presente però che quest'ultima è allocata
+staticamente, per cui viene sovrascritta tutte le volte che si ripete la
+lettura di una voce sullo stesso stream.
+
+Di questa funzione esiste anche una versione rientrante, \func{readdir\_r},
+che non usa una struttura allocata staticamente, e può essere utilizzata anche
+con i thread; il suo prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} \headdecl{dirent.h} 
+  
+  \funcdecl{int readdir\_r(DIR *dir, struct dirent *entry,
+          struct dirent **result)}
+  
+  Legge una voce dal \textit{directory stream}.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+    errore, gli errori sono gli stessi di \func{readdir}.}
+\end{functions}
 
+La funzione restituisce in \param{result} (come \textit{value result
+  argument}) l'indirizzo dove sono stati salvati i dati, che di norma
+corrisponde a quello della struttura precedentemente allocata e specificata
+dall'argomento \param{entry} (anche se non è assicurato che la funzione usi lo
+spazio fornito dall'utente).
+
+I vari campi di \struct{dirent} contengono le informazioni relative alle voci
+presenti nella directory; sia BSD che SVr4\footnote{POSIX prevede invece solo
+  la presenza del campo \var{d\_fileno}, identico \var{d\_ino}, che in Linux è
+  definito come alias di quest'ultimo. Il campo \var{d\_name} è considerato
+  dipendente dall'implementazione.} prevedono che siano sempre presenti il
+campo \var{d\_name}, che contiene il nome del file nella forma di una stringa
+terminata da uno zero,\footnote{lo standard POSIX non specifica una lunghezza,
+  ma solo un limite \const{NAME\_MAX}; in SVr4 la lunghezza del campo è
+  definita come \code{NAME\_MAX+1} che di norma porta al valore di 256 byte
+  usato anche in Linux.} ed il campo \var{d\_ino}, che contiene il numero di
+inode cui il file è associato (di solito corrisponde al campo \var{st\_ino} di
+\struct{stat}).
 
 \begin{figure}[!htb]
-  \footnotesize
-  \centering
+  \footnotesize \centering
   \begin{minipage}[c]{15cm}
-    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-struct dirent {
-    ino_t d_ino;
-    unsigned short int d_reclen;
-    unsigned char d_type;
-    char d_name[256];           /* We must not include limits.h! */
-};
-    \end{lstlisting}
+    \includestruct{listati/dirent.c}
   \end{minipage} 
   \normalsize 
   \caption{La struttura \structd{dirent} per la lettura delle informazioni dei 
@@ -731,16 +795,255 @@ struct dirent {
   \label{fig:file_dirent_struct}
 \end{figure}
 
+La presenza di ulteriori campi opzionali è segnalata dalla definizione di
+altrettante macro nella forma \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è
+il nome del relativo campo; nel nostro caso sono definite le macro
+\macro{\_DIRENT\_HAVE\_D\_TYPE}, \macro{\_DIRENT\_HAVE\_D\_OFF} e
+\macro{\_DIRENT\_HAVE\_D\_RECLEN}.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|l|}
+    \hline
+    \textbf{Valore} & \textbf{Significato} \\
+    \hline
+    \hline
+    \const{DT\_UNKNOWN} & tipo sconosciuto. \\
+    \const{DT\_REG}     & file normale. \\
+    \const{DT\_DIR}     & directory. \\
+    \const{DT\_FIFO}    & fifo. \\
+    \const{DT\_SOCK}    & socket. \\
+    \const{DT\_CHR}     & dispositivo a caratteri. \\
+    \const{DT\_BLK}     & dispositivo a blocchi. \\
+    \hline    
+  \end{tabular}
+  \caption{Costanti che indicano i vari tipi di file nel campo \var{d\_type}
+    della struttura \struct{dirent}.}
+  \label{tab:file_dtype_macro}
+\end{table}
+
+Per quanto riguarda il significato dei campi opzionali, il campo \var{d\_type}
+indica il tipo di file (fifo, directory, link simbolico, ecc.); i suoi
+possibili valori\footnote{fino alla versione 2.1 delle \acr{glibc} questo
+  campo, pur presente nella struttura, non è implementato, e resta sempre al
+  valore \const{DT\_UNKNOWN}.}  sono riportati in
+\tabref{tab:file_dtype_macro}; per la conversione da e verso l'analogo valore
+mantenuto dentro il campo \var{st\_mode} di \struct{stat} sono definite anche
+due macro di conversione \macro{IFTODT} e \macro{DTTOIF}:
+\begin{functions}
+  \funcdecl{int IFTODT(mode\_t MODE)} Converte il tipo di file dal formato di
+  \var{st\_mode} a quello di \var{d\_type}.
+  
+  \funcdecl{mode\_t DTTOIF(int DTYPE)} Converte il tipo di file dal formato di
+  \var{d\_type} a quello di \var{st\_mode}.
+\end{functions}
+
+Il campo \var{d\_off} contiene invece la posizione della voce successiva della
+directory, mentre il campo \var{d\_reclen} la lunghezza totale della voce
+letta. Con questi due campi diventa possibile, determinando la posizione delle
+varie voci, spostarsi all'interno dello stream usando la funzione
+\func{seekdir},\footnote{sia questa funzione che \func{telldir}, sono
+  estensioni prese da BSD, non previste dallo standard POSIX.} il cui
+prototipo è:
+\begin{prototype}{dirent.h}{void seekdir(DIR *dir, off\_t offset)}
+  Cambia la posizione all'interno di un \textit{directory stream}.
+\end{prototype}
+
+La funzione non ritorna nulla e non segnala errori, è però necessario che il
+valore dell'argomento \param{offset} sia valido per lo stream \param{dir};
+esso pertanto deve essere stato ottenuto o dal valore di \var{d\_off} di
+\struct{dirent} o dal valore restituito dalla funzione \func{telldir}, che
+legge la posizione corrente; il prototipo di quest'ultima è:
+\begin{prototype}{dirent.h}{off\_t telldir(DIR *dir)}
+  Ritorna la posizione corrente in un \textit{directory stream}.
+  
+  \bodydesc{La funzione restituisce la posizione corrente nello stream (un
+    numero positivo) in caso di successo, e -1 altrimenti, nel qual caso
+    \var{errno} assume solo il valore di \errval{EBADF}, corrispondente ad un
+    valore errato per \param{dir}.}
+\end{prototype}
+
+La sola funzione di posizionamento nello stream prevista dallo standard POSIX
+è \funcd{rewinddir}, che riporta la posizione a quella iniziale; il suo
+prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} \headdecl{dirent.h} 
+  
+  \funcdecl{void rewinddir(DIR *dir)}
+  
+  Si posiziona all'inizio di un \textit{directory stream}.
+\end{functions}
+
+
+Una volta completate le operazioni si può chiudere il \textit{directory
+  stream} con la funzione \funcd{closedir}, il cui prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} \headdecl{dirent.h} 
+  
+  \funcdecl{int closedir(DIR * dir)} 
+  
+  Chiude un \textit{directory stream}.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 altrimenti, nel
+    qual caso \var{errno} assume il valore \errval{EBADF}.}
+\end{functions}
+
+A parte queste funzioni di base in BSD 4.3 è stata introdotta un'altra
+funzione che permette di eseguire una scansione completa (con tanto di ricerca
+ed ordinamento) del contenuto di una directory; la funzione è
+\funcd{scandir}\footnote{in Linux questa funzione è stata introdotta fin dalle
+  libc4.} ed il suo prototipo è:
+\begin{prototype}{dirent.h}{int scandir(const char *dir, 
+    struct dirent ***namelist, int(*select)(const struct dirent *),
+    int(*compar)(const struct dirent **, const struct dirent **))} 
+  
+  Esegue una scansione di un \textit{directory stream}.
+  
+  \bodydesc{La funzione restituisce in caso di successo il numero di voci
+    trovate, e -1 altrimenti.}
+\end{prototype}
+
+Al solito, per la presenza fra gli argomenti di due puntatori a funzione, il
+prototipo non è molto comprensibile; queste funzioni però sono quelle che
+controllano rispettivamente la selezione di una voce (\param{select}) e
+l'ordinamento di tutte le voci selezionate (\param{compar}). 
+
+La funzione legge tutte le voci della directory indicata dall'argomento
+\param{dir}, passando ciascuna di esse come argomento alla funzione di
+\param{select}; se questa ritorna un valore diverso da zero la voce viene
+inserita in una struttura allocata dinamicamente con \func{malloc}, qualora si
+specifichi un valore \val{NULL} per \func{select} vengono selezionate tutte le
+voci. Tutte le voci selezionate vengono poi inserite un una lista (anch'essa
+allocata con \func{malloc}, che viene riordinata tramite \func{qsort} usando
+la funzione \param{compar} come criterio di ordinamento; alla fine l'indirizzo
+della lista ordinata è restituito nell'argomento \param{namelist}.
+
+Per l'ordinamento sono disponibili anche due funzioni predefinite,
+\funcd{alphasort} e \funcd{versionsort}, i cui prototipi sono:
+\begin{functions}
+  \headdecl{dirent.h} 
+  
+  \funcdecl{int alphasort(const void *a, const void *b)} 
+
+  \funcdecl{int versionsort(const void *a, const void *b)} 
+  
+  Funzioni per l'ordinamento delle voci di \textit{directory stream}.
+  
+  \bodydesc{Le funzioni restituiscono un valore minore, uguale o maggiore di
+    zero qualora il primo argomento sia rispettivamente minore, uguale o
+    maggiore del secondo.}
+\end{functions}
+
+La funzione \func{alphasort} deriva da BSD ed è presente in Linux fin dalle
+libc4\footnote{la versione delle libc4 e libc5 usa però come argomenti dei
+  puntatori a delle strutture \struct{dirent}; le glibc usano il prototipo
+  originario di BSD, mostrato anche nella definizione, che prevede puntatori a
+  \ctyp{void}.}  e deve essere specificata come argomento \param{compare} per
+ottenere un ordinamento alfabetico (secondo il valore del campo \var{d\_name}
+delle varie voci). Le \acr{glibc} prevedono come estensione\footnote{le glibc,
+  a partire dalla versione 2.1, effettuano anche l'ordinamento alfabetico
+  tenendo conto delle varie localizzazioni, usando \func{strcoll} al posto di
+  \func{strcmp}.} anche \func{versionsort}, che ordina i nomi tenendo conto
+del numero di versione (cioè qualcosa per cui \file{file10} viene comunque
+dopo \func{file4}.)
+
+Un semplice esempio dell'uso di queste funzioni è riportato in
+\figref{fig:file_my_ls}, dove si è riportata la sezione principale di un
+programma che, usando la routine di scansione illustrata in
+\figref{fig:file_dirscan}, stampa i nomi dei file contenuti in una directory e
+la relativa dimensione (in sostanza una versione semplificata del comando
+\cmd{ls}).
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15.6cm}
+    \includecodesample{listati/my_ls.c}
+  \end{minipage}
+  \caption{Esempio di codice per eseguire la lista dei file contenuti in una
+    directory.} 
+  \label{fig:file_my_ls}
+\end{figure}
+
+Il programma è estremamente semplice; in \figref{fig:file_my_ls} si è omessa
+la parte di gestione delle opzioni (che prevede solo l'uso di una funzione per
+la stampa della sintassi, anch'essa omessa) ma il codice completo potrà essere
+trovato coi sorgenti allegati nel file \file{myls.c}.
+
+In sostanza tutto quello che fa il programma, dopo aver controllato
+(\texttt{\small 10--13}) di avere almeno un parametro (che indicherà la
+directory da esaminare) è chiamare (\texttt{\small 14}) la funzione
+\func{DirScan} per eseguire la scansione, usando la funzione \code{do\_ls}
+(\texttt{\small 20--26}) per fare tutto il lavoro. 
+
+Quest'ultima si limita (\texttt{\small 23}) a chiamare \func{stat} sul file
+indicato dalla directory entry passata come argomento (il cui nome è appunto
+\var{direntry->d\_name}), memorizzando in una opportuna struttura \var{data} i
+dati ad esso relativi, per poi provvedere (\texttt{\small 24}) a stampare il
+nome del file e la dimensione riportata in \var{data}.  
+
+Dato che la funzione verrà chiamata all'interno di \func{DirScan} per ogni
+voce presente questo è sufficiente a stampare la lista completa dei file e
+delle relative dimensioni.  Si noti infine come si restituisca sempre 0 come
+valore di ritorno per indicare una esecuzione senza errori.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15.6cm}
+    \includecodesample{listati/DirScan.c}
+  \end{minipage}
+  \caption{Codice della routine di scansione di una directory contenuta nel
+    file \file{DirScan.c}.} 
+  \label{fig:file_dirscan}
+\end{figure}
 
+Tutto il grosso del lavoro è svolto dalla funzione \func{DirScan}, riportata
+in \figref{fig:file_dirscan}. La funzione è volutamente generica e permette di
+eseguire una funzione, passata come secondo argomento, su tutte le voci di una
+directory.  La funzione inizia con l'aprire (\texttt{\small 19--23}) uno
+stream sulla directory passata come primo argomento, stampando un messaggio in
+caso di errore.
+
+Il passo successivo (\texttt{\small 24--25}) è cambiare directory di lavoro
+(vedi \secref{sec:file_work_dir}), usando in sequenza le funzione \func{dirfd}
+e \func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir}
+su \var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
+  27--31}) sulle singole voci dello stream ci si trovi all'interno della
+directory.\footnote{questo è essenziale al funzionamento della funzione
+  \code{do\_ls} (e ad ogni funzione che debba usare il campo \var{d\_name}, in
+  quanto i nomi dei file memorizzati all'interno di una struttura
+  \struct{dirent} sono sempre relativi alla directory in questione, e senza
+  questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere
+  le dimensioni.}
+
+Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
+alla funzione passata come secondo argomento, il ciclo di scansione della
+directory è molto semplice; si legge una voce alla volta (\texttt{\small 27})
+all'interno di una istruzione di \code{while} e fintanto che si riceve una
+voce valida (cioè un puntatore diverso da \val{NULL}) si esegue
+(\texttt{\small 27}) la funzione di elaborazione \var{compare} (che nel nostro
+caso sarà \code{do\_ls}), ritornando con un codice di errore (\texttt{\small
+  28}) qualora questa presenti una anomalia (identificata da un codice di
+ritorno negativo).
+
+Una volta terminato il ciclo la funzione si conclude con la chiusura
+(\texttt{\small 32}) dello stream\footnote{nel nostro caso, uscendo subito
+  dopo la chiamata, questo non servirebbe, in generale però l'operazione è
+  necessaria, dato che la funzione può essere invocata molte volte all'interno
+  dello stesso processo, per cui non chiudere gli stream comporterebbe un
+  consumo progressivo di risorse, con conseguente rischio di esaurimento delle
+  stesse} e la restituzione (\texttt{\small 33}) del codice di operazioni
+concluse con successo.
 
 
 \subsection{La directory di lavoro}
 \label{sec:file_work_dir}
 
 A ciascun processo è associata una directory nel filesystem che è chiamata
-directory corrente o directory di lavoro (\textit{current working directory})
-che è quella a cui si fa riferimento quando un filename è espresso in forma
-relativa, dove il ``relativa'' fa riferimento appunto a questa directory.
+\textsl{directory corrente} o \textsl{directory di lavoro} (in inglese
+\textit{current working directory}) che è quella a cui si fa riferimento
+quando un pathname è espresso in forma relativa, dove il ``\textsl{relativa}''
+fa riferimento appunto a questa directory.
 
 Quando un utente effettua il login, questa directory viene impostata alla
 \textit{home directory} del suo account. Il comando \cmd{cd} della shell
@@ -751,12 +1054,10 @@ resta la stessa quando viene creato un processo figlio (vedi
 directory corrente di qualunque comando da essa lanciato.
 
 In genere il kernel tiene traccia per ciascun processo dell'inode\index{inode}
-della directory di lavoro corrente, per ottenere il pathname occorre usare una
-apposita funzione di libreria, \func{getcwd}, il cui prototipo è:
+della directory di lavoro, per ottenere il pathname occorre usare una apposita
+funzione di libreria, \funcd{getcwd}, il cui prototipo è:
 \begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}
-  Restituisce il filename completo della directory di lavoro corrente nella
-  stringa puntata da \param{buffer}, che deve essere precedentemente allocata,
-  per una dimensione massima di \param{size}.
+  Legge il pathname della directory di lavoro corrente.
   
   \bodydesc{La funzione restituisce il puntatore \param{buffer} se riesce,
     \val{NULL} se fallisce, in quest'ultimo caso la variabile
@@ -772,15 +1073,19 @@ apposita funzione di libreria, \func{getcwd}, il cui prototipo 
   \end{errlist}}
 \end{prototype}
 
-Il buffer deve essere sufficientemente lungo da poter contenere il pathname
-completo più lo zero di terminazione della stringa. Qualora esso ecceda le
-dimensioni specificate con \param{size} la funzione restituisce un errore.  Si
-può anche specificare un puntatore nullo come \param{buffer},\footnote{questa è
-  un'estensione allo standard POSIX.1, supportata da Linux.} nel qual caso la
-stringa sarà allocata automaticamente per una dimensione pari a \param{size}
-qualora questa sia diversa da zero, o della lunghezza esatta del pathname
-altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una
-volta cessato il suo utilizzo.
+La funzione restituisce il pathname completo della directory di lavoro nella
+stringa puntata da \param{buffer}, che deve essere precedentemente allocata,
+per una dimensione massima di \param{size}.  Il buffer deve essere
+sufficientemente lungo da poter contenere il pathname completo più lo zero di
+terminazione della stringa. Qualora esso ecceda le dimensioni specificate con
+\param{size} la funzione restituisce un errore.
+
+Si può anche specificare un puntatore nullo come
+\param{buffer},\footnote{questa è un'estensione allo standard POSIX.1,
+  supportata da Linux.} nel qual caso la stringa sarà allocata automaticamente
+per una dimensione pari a \param{size} qualora questa sia diversa da zero, o
+della lunghezza esatta del pathname altrimenti. In questo caso ci si deve
+ricordare di disallocare la stringa una volta cessato il suo utilizzo.
 
 Di questa funzione esiste una versione \code{char *getwd(char *buffer)}
 fatta per compatibilità all'indietro con BSD, che non consente di specificare
@@ -799,11 +1104,11 @@ dei link simbolici. Usando \func{getcwd} infatti, essendo il 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
-\func{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta
-appunto per \textit{change directory}, il suo prototipo è:
+Per cambiare la directory di lavoro si può usare la funzione \funcd{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}.
+  Cambia la directory di lavoro in \param{pathname}.
   
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
     nel qual caso \var{errno} assumerà i valori:
@@ -819,8 +1124,8 @@ appunto per \textit{change directory}, il suo prototipo 
 quale si hanno i permessi di accesso.
 
 Dato che anche le directory sono file, è possibile riferirsi ad esse anche
-tramite il file descriptor, e non solo tramite il filename, per fare questo si
-usa \func{fchdir}, il cui prototipo è:
+tramite il file descriptor, e non solo tramite il pathname, per fare questo si
+usa \funcd{fchdir}, il cui prototipo è:
 \begin{prototype}{unistd.h}{int fchdir(int fd)} 
   Identica a \func{chdir}, ma usa il file descriptor \param{fd} invece del
   pathname.
@@ -845,11 +1150,12 @@ sembri semplice, in realt
 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
 controllo e la creazione si ha giusto lo spazio per una possibile \textit{race
-  condition} (si ricordi quanto visto in \secref{sec:proc_race_cond}).
+  condition}\index{race condition} (si ricordi quanto visto in
+\secref{sec:proc_race_cond}).
 
 Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei,
 di cui si abbia certezza di unicità (al momento della generazione); la prima
-di queste funzioni è \func{tmpnam} il cui prototipo è:
+di queste funzioni è \funcd{tmpnam} il cui prototipo è:
 \begin{prototype}{stdio.h}{char *tmpnam(char *string)}
   Restituisce il puntatore ad una stringa contente un nome di file valido e
   non esistente al momento dell'invocazione. 
@@ -868,7 +1174,7 @@ prefisso la directory specificata da \const{P\_tmpdir}.
 
 Di questa funzione esiste una versione rientrante, \func{tmpnam\_r}, che non
 fa nulla quando si passa \val{NULL} come parametro. Una funzione simile,
-\func{tempnam}, permette di specificare un prefisso per il file
+\funcd{tempnam}, permette di specificare un prefisso per il file
 esplicitamente, il suo prototipo è:
 \begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
   Restituisce il puntatore ad una stringa contente un nome di file valido e
@@ -904,7 +1210,7 @@ queste funzioni occorre sempre aprire il nuovo file in modalit
 esistente.
 
 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
-POSIX definisce la funzione \func{tempfile}, il cui prototipo è:
+POSIX definisce la funzione \funcd{tempfile}, il cui prototipo è:
 \begin{prototype}{stdio.h}{FILE *tmpfile (void)}
   Restituisce un file temporaneo aperto in lettura/scrittura.
   
@@ -927,10 +1233,10 @@ funzione 
   condition}\index{race condition}.
 
 Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
-caso si possono usare le vecchie funzioni \func{mktemp} e \func{mkstemp} che
+caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
 modificano una stringa di input che serve da modello e che deve essere
 conclusa da 6 caratteri \code{X} che verranno sostituiti da un codice
-unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
+unico. La prima delle due è analoga a \funcd{tmpnam} e genera un nome casuale,
 il suo prototipo è:
 \begin{prototype}{stlib.h}{char *mktemp(char *template)}
   Genera un filename univoco sostituendo le \code{XXXXXX} finali di
@@ -947,15 +1253,13 @@ il suo prototipo 
 funzione non si può usare una stringa costante.  Tutte le avvertenze riguardo
 alle possibili \textit{race condition}\index{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à 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.
-
+il valore 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à
+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.
 
-
-La seconda funzione, \func{mkstemp} è sostanzialmente equivalente a
+La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
 \func{tmpfile}, ma restituisce un file descriptor invece di uno stream; il suo
 prototipo è:
 \begin{prototype}{stlib.h}{int mkstemp(char *template)}
@@ -966,7 +1270,7 @@ prototipo 
     -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
-    \item[\errcode{EEXIST}] non è riuscita a creare un file temporano, il
+    \item[\errcode{EEXIST}] non è riuscita a creare un file temporaneo, il
       contenuto di \param{template} è indefinito.
     \end{errlist}}
 \end{prototype}
@@ -982,7 +1286,7 @@ certezza di essere i soli utenti del file. I permessi sono impostati al valore
 
 In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
   Linux a partire dalle \acr{glibc} 2.1.91.} simile alle precedenti,
-\func{mkdtemp}, che crea una directory temporanea; il suo prototipo è:
+\funcd{mkdtemp}, che crea una directory temporanea; il suo prototipo è:
 \begin{prototype}{stlib.h}{char *mkdtemp(char *template)}
   Genera una directory temporaneo il cui nome è ottenuto sostituendo le
   \code{XXXXXX} finali di \param{template}.
@@ -1035,7 +1339,7 @@ seguenti:
   
   \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
   \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
-  lette le informazioni relativa ad esso e non al file a cui fa riferimento.
+  lette le informazioni relativae ad esso e non al file a cui fa riferimento.
   
   \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
   eccetto che si usa con un file aperto, specificato tramite il suo file
@@ -1060,23 +1364,7 @@ riservati per estensioni come tempi pi
   \footnotesize
   \centering
   \begin{minipage}[c]{15cm}
-    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-struct stat {
-    dev_t         st_dev;      /* device */
-    ino_t         st_ino;      /* inode */
-    mode_t        st_mode;     /* protection */
-    nlink_t       st_nlink;    /* number of hard links */
-    uid_t         st_uid;      /* user ID of owner */
-    gid_t         st_gid;      /* group ID of owner */
-    dev_t         st_rdev;     /* device type (if inode device) */
-    off_t         st_size;     /* total size, in bytes */
-    unsigned long st_blksize;  /* blocksize for filesystem I/O */
-    unsigned long st_blocks;   /* number of blocks allocated */
-    time_t        st_atime;    /* time of last access */
-    time_t        st_mtime;    /* time of last modification */
-    time_t        st_ctime;    /* time of last change */
-};
-    \end{lstlisting}
+    \includestruct{listati/stat.h}
   \end{minipage} 
   \normalsize 
   \caption{La struttura \structd{stat} per la lettura delle informazioni dei 
@@ -1095,7 +1383,7 @@ primitivi del sistema (di quelli definiti in
 Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e alle
 directory esistono 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).
+\var{st\_mode} (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 file,
@@ -1144,7 +1432,7 @@ un'opportuna combinazione.
     \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \const{S\_IFMT}   &  0170000 & bitmask per i bit del tipo di file \\
+    \const{S\_IFMT}   &  0170000 & maschera per i bit del tipo di file \\
     \const{S\_IFSOCK} &  0140000 & socket\index{socket}             \\
     \const{S\_IFLNK}  &  0120000 & link simbolico     \\
     \const{S\_IFREG}  &  0100000 & file regolare      \\ 
@@ -1181,9 +1469,7 @@ un'opportuna combinazione.
 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}
+\includecodesnip{listati/is_file_dir.h}
 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.
 
@@ -1410,7 +1696,7 @@ avr
 \label{sec:file_utime}
 
 I tempi di ultimo accesso e modifica possono essere cambiati usando la
-funzione \func{utime}, il cui prototipo è:
+funzione \funcd{utime}, il cui prototipo è:
 \begin{prototype}{utime.h}
 {int utime(const char *filename, struct utimbuf *times)} 
 
@@ -1434,12 +1720,7 @@ valori che si vogliono impostare per tempi.
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
-    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-struct utimbuf {
-        time_t actime;  /* access time */
-        time_t modtime; /* modification time */
-};
-    \end{lstlisting}
+    \includestruct{listati/utimbuf.h}
   \end{minipage} 
   \normalsize 
   \caption{La struttura \structd{utimbuf}, usata da \func{utime} per modificare
@@ -1472,7 +1753,7 @@ Una delle caratteristiche fondamentali di tutti i sistemi unix-like 
 del controllo di accesso ai file, che viene implementato per qualunque
 filesystem standard.\footnote{per standard si intende che implementa le
   caratteristiche previste dallo standard POSIX. In Linux sono disponibili
-  anche una serie di altri filesystem, come quelli di Windiws e del Mac, che
+  anche una serie di altri filesystem, come quelli di Windows e del Mac, che
   non supportano queste caratteristiche.} In questa sezione ne esamineremo i
 concetti essenziali e le funzioni usate per gestirne i vari aspetti.
 
@@ -1521,12 +1802,6 @@ meno significativi sono usati a gruppi di tre per indicare i permessi base di
 lettura, scrittura ed esecuzione e sono applicati rispettivamente
 rispettivamente al proprietario, al gruppo, a tutti gli altri.
 
-I restanti tre bit (noti come \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}); lo schema di
-allocazione dei bit è riportato in \figref{fig:file_perm_bit}.
-
 \begin{figure}[htb]
   \centering
   \includegraphics[width=6cm]{img/fileperm}
@@ -1535,6 +1810,12 @@ allocazione dei bit 
   \label{fig:file_perm_bit}
 \end{figure}
 
+I restanti tre bit (noti come \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}); lo schema di
+allocazione dei bit è riportato in \figref{fig:file_perm_bit}.
+
 Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
 memorizzati nell'inode\index{inode}; in particolare essi sono contenuti in
 alcuni bit del campo \var{st\_mode} della struttura \struct{stat} (si veda di
@@ -1589,6 +1870,7 @@ la quale appunto serve il diritto di esecuzione).
 Per una directory infatti il permesso di esecuzione significa che essa può
 essere attraversata nella risoluzione del pathname, ed è distinto dal permesso
 di lettura che invece implica che si può leggere il contenuto della directory.
+
 Questo significa che se si ha il permesso di esecuzione senza permesso di
 lettura si potrà lo stesso aprire un file in una directory (se si hanno i
 permessi opportuni per il medesimo) ma non si potrà vederlo con \cmd{ls}
@@ -1625,8 +1907,8 @@ in una directory con lo \textsl{sticky bit} impostato (si veda
 La procedura con cui il kernel stabilisce se un processo possiede un certo
 permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
 l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
-\var{st\_gid} accennati in precedenza) e l'userid effettivo, il groupid
-effettivo e gli eventuali groupid supplementari del processo.\footnote{in
+\var{st\_gid} accennati in precedenza) e l'user-ID effettivo, il group-ID
+effettivo e gli eventuali group-ID supplementari del processo.\footnote{in
   realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli gli
   identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
   \secref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
@@ -1635,19 +1917,19 @@ effettivo e gli eventuali groupid supplementari del processo.\footnote{in
 
 Per una spiegazione dettagliata degli identificatori associati ai processi si
 veda \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in
-\secref{sec:file_suid_sgid}, l'userid effettivo e il groupid effectivo
+\secref{sec:file_suid_sgid}, l'user-ID effettivo e il group-ID effettivo
 corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
-lanciato il processo, mentre i groupid supplementari sono quelli dei gruppi
+lanciato il processo, mentre i group-ID supplementari sono quelli dei gruppi
 cui l'utente appartiene.
 
 I passi attraverso i quali viene stabilito se il processo possiede il diritto
 di accesso sono i seguenti:
 \begin{enumerate}
-\item Se l'userid effettivo del processo è zero (corrispondente
+\item Se l'user-ID effettivo del processo è zero (corrispondente
   all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
   controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
   tutti i file.
-\item Se l'userid effettivo del processo è uguale all'\acr{uid} del
+\item Se l'user-ID effettivo del processo è uguale all'\acr{uid} del
   proprietario del file (nel qual caso si dice che il processo è proprietario
   del file) allora:
   \begin{itemize*}
@@ -1657,8 +1939,8 @@ di accesso sono i seguenti:
     impostato, l'accesso è consentito
   \item altrimenti l'accesso è negato
   \end{itemize*}
-\item Se il groupid effettivo del processo o uno dei groupid supplementari dei
-  processi corrispondono al \acr{gid} del file allora:
+\item Se il group-ID effettivo del processo o uno dei group-ID supplementari
+  dei processi corrispondono al \acr{gid} del file allora:
   \begin{itemize*}
   \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
     consentito, 
@@ -1691,24 +1973,24 @@ Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
 programma il comportamento normale del kernel è quello di impostare gli
 identificatori del gruppo \textit{effective} del nuovo processo al valore dei
 corrispondenti del gruppo \textit{real} del processo corrente, che normalmente
-corrispondono dell'utente con cui si è entrati nel sistema.
+corrispondono a quelli dell'utente con cui si è entrati nel sistema.
 
 Se però il file del programma (che ovviamente deve essere
 eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid}
   e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il
-kernel assegnerà come userid effettivo al nuovo processo l'\acr{uid} del
+kernel assegnerà come user-ID effettivo al nuovo processo l'\acr{uid} del
 proprietario del file al posto dell'\acr{uid} del processo originario.  Avere
-il bit \acr{sgid} impostato ha lo stesso effetto sul groupid effettivo del
+il bit \acr{sgid} impostato ha lo stesso effetto sul group-ID effettivo del
 processo.
 
 I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
-di usare programmi che abbisognano di privilegi speciali; l'esempio classico è
-il comando \cmd{passwd} che ha la necessità di modificare il file delle
-password, quest'ultimo ovviamente può essere scritto solo dall'amministratore,
-ma non è necessario chiamare l'amministratore per cambiare la propria
-password. Infatti il comando \cmd{passwd} appartiene a root ma ha il bit
-\acr{suid} impostato per cui quando viene lanciato da un utente normale parte
-con i privilegi di root.
+di usare programmi che richiedono privilegi speciali; l'esempio classico è il
+comando \cmd{passwd} che ha la necessità di modificare il file delle password,
+quest'ultimo ovviamente può essere scritto solo dall'amministratore, ma non è
+necessario chiamare l'amministratore per cambiare la propria password. Infatti
+il comando \cmd{passwd} appartiene a root ma ha il bit \acr{suid} impostato
+per cui quando viene lanciato da un utente normale parte con i privilegi di
+root.
 
 Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
 normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
@@ -1774,16 +2056,17 @@ condizioni:
 \item l'utente è l'amministratore 
 \end{itemize*}
 un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
-permessi infatti di solito sono impostati come:
+permessi infatti di solito sono i seguenti:
 \begin{verbatim}
 $ ls -ld /tmp
 drwxrwxrwt    6 root     root         1024 Aug 10 01:03 /tmp
 \end{verbatim}%$
-in questo modo chiunque può creare file in questa directory (che infatti è
-normalmente utilizzata per la creazione di file temporanei), ma solo l'utente
-che ha creato un certo file potrà cancellarlo o rinominarlo. In questo modo si
-evita che un utente possa, più o meno consapevolmente, cancellare i file degli
-altri.
+quindi con lo \textsl{sticky bit} bit impostato. In questo modo qualunque
+utente nel sistema può creare dei file in questa directory (che, come
+suggerisce il nome, è normalmente utilizzata per la creazione di file
+temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o
+rinominarlo. In questo modo si evita che un utente possa, più o meno
+consapevolmente, cancellare i file temporanei creati degli altri utenti.
 
 
 \subsection{La titolarità di nuovi file e directory}
@@ -1792,15 +2075,15 @@ altri.
 Vedremo in \secref{sec:file_base_func} con quali funzioni si possono creare
 nuovi file, in tale occasione vedremo che è possibile specificare in sede di
 creazione quali permessi applicare ad un file, però non si può indicare a
-quale utente e gruppo esso deve appartenere.  Lo stesso problema di presenta
+quale utente e gruppo esso deve appartenere.  Lo stesso problema si presenta
 per la creazione di nuove directory (procedimento descritto in
 \secref{sec:file_dir_creat_rem}).
 
 Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
-all'userid effettivo del processo che lo crea; per il \acr{gid} invece prevede
+all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede
 due diverse possibilità:
 \begin{itemize*}
-\item il \acr{gid} del file corrisponde al groupid effettivo del processo.
+\item il \acr{gid} del file corrisponde al group-ID effettivo del processo.
 \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
   esso è creato.
 \end{itemize*}
@@ -1812,31 +2095,32 @@ bit \acr{sgid} impostato allora viene usata la seconda opzione.
 
 Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
 automaticamente propagato, restando coerente a quello della directory di
-partenza, in tutte le sottodirectory. La semantica SVr4 offre la possibilità
-di scegliere, ma per ottenere lo stesso risultato di coerenza che si ha con
-BSD necessita che per le nuove directory venga anche propagato anche il bit
-\acr{sgid}. Questo è il comportamento predefinito di \cmd{mkdir}, ed è in
-questo modo ad esempio che Debian assicura che le sottodirectory create nella
-home di un utente restino sempre con il \acr{gid} del gruppo primario dello
-stesso.
+partenza, in tutte le sotto-directory. 
+
+La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
+risultato di coerenza che si ha con BSD necessita che per le nuove directory
+venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento
+predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che Debian
+assicura che le sotto-directory create nella home di un utente restino sempre
+con il \acr{gid} del gruppo primario dello stesso.
 
 
 \subsection{La funzione \func{access}}
 \label{sec:file_access}
 
 Come visto in \secref{sec:file_access_control} il controllo di accesso ad un
-file viene fatto utilizzando l'userid ed il groupid effettivo del processo; ci
-sono casi però in cui si può voler effettuare il controllo con l'userid reale
-ed il groupid reale, vale a dire usando i valori di \acr{uid} e \acr{gid}
+file viene fatto utilizzando l'user-ID ed il group-ID effettivo del processo; ci
+sono casi però in cui si può voler effettuare il controllo con l'user-ID reale
+ed il group-ID reale, vale a dire usando i valori di \acr{uid} e \acr{gid}
 relativi all'utente che ha lanciato il programma, e che, come accennato in
 \secref{sec:file_suid_sgid} e spiegato in dettaglio in
-\secref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.  Per far
-questo si può usare la funzione \func{access}, il cui prototipo è:
+\secref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.  
+
+Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:
 \begin{prototype}{unistd.h}
 {int access(const char *pathname, int mode)}
 
-Verifica i permessi di accesso, indicati da \param{mode}, per il file indicato
-da \param{pathname}.
+Verifica i permessi di accesso.
   
 \bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
   è consentito ed in caso di errore; nel qual caso la variabile \var{errno}
@@ -1852,14 +2136,15 @@ da \param{pathname}.
   \errval{ENOTDIR}, \errval{ELOOP}, \errval{EIO}.}
 \end{prototype}
 
-I valori possibili per l'argomento \param{mode} sono esprimibili come
-combinazione delle costanti numeriche riportate in
-\tabref{tab:file_access_mode_val} (attraverso un OR binario delle stesse). I
-primi tre valori implicano anche la verifica dell'esistenza del file, se si
-vuole verificare solo quest'ultima si può usare \const{F\_OK}, o anche
-direttamente \func{stat}. Nel caso in cui \param{pathname} si riferisca ad un
-link simbolico, questo viene seguito ed il controllo è fatto sul file a cui
-esso fa riferimento.
+La funzione verifica i permessi di accesso, indicati da \param{mode}, per il
+file indicato da \param{pathname}. I valori possibili per l'argomento
+\param{mode} sono esprimibili come combinazione delle costanti numeriche
+riportate in \tabref{tab:file_access_mode_val} (attraverso un OR binario delle
+stesse). I primi tre valori implicano anche la verifica dell'esistenza del
+file, se si vuole verificare solo quest'ultima si può usare \const{F\_OK}, o
+anche direttamente \func{stat}. Nel caso in cui \param{pathname} si riferisca
+ad un link simbolico, questo viene seguito ed il controllo è fatto sul file a
+cui esso fa riferimento.
 
 La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
 fatto che una directory abbia permesso di scrittura non significa che ci si
@@ -1911,7 +2196,7 @@ filename e su un file descriptor, i loro prototipi sono:
   \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
     un errore, in caso di errore \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{EPERM}] L'userid effettivo non corrisponde a quello del
+  \item[\errcode{EPERM}] L'user-ID effettivo non corrisponde a quello del
     proprietario del file o non è zero.
     \item[\errcode{EROFS}] Il file è su un filesystem in sola lettura.
   \end{errlist}
@@ -1974,7 +2259,7 @@ bit \acr{suid} il valore da fornire sarebbe $4755$.
 
 Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
 comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
-funzioni infatti è possibile solo se l'userid effettivo del processo
+funzioni infatti è possibile solo se l'user-ID effettivo del processo
 corrisponde a quello del proprietario del file o dell'amministratore,
 altrimenti esse falliranno con un errore di \errcode{EPERM}.
 
@@ -1984,7 +2269,7 @@ non tutti i valori possibili di \param{mode} sono permessi o hanno effetto;
 in particolare accade che:
 \begin{enumerate}
 \item siccome solo l'amministratore può impostare lo \textit{sticky bit}, se
-  l'userid effettivo del processo non è zero esso viene automaticamente
+  l'user-ID effettivo del processo non è zero esso viene automaticamente
   cancellato (senza notifica di errore) qualora sia stato indicato in
   \param{mode}.
 \item per quanto detto in \secref{sec:file_ownership} riguardo la creazione
@@ -1994,7 +2279,7 @@ in particolare accade che:
   per cui non si hanno diritti, questo viene automaticamente cancellato da
   \param{mode} (senza notifica di errore) qualora il gruppo del file non
   corrisponda a quelli associati al processo (la cosa non avviene quando
-  l'userid effettivo del processo è zero).
+  l'user-ID effettivo del processo è zero).
 \end{enumerate}
 
 Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
@@ -2009,9 +2294,29 @@ perdita di questo privilegio.
 \subsection{La funzione \func{umask}}
 \label{sec:file_umask}
 
-Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
-nuovi file sono controllati anche da una maschera di bit impostata con la
-funzione \func{umask}, il cui prototipo è:
+Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
+permessi di un file, resta però il problema di quali sono i permessi assegnati
+quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come
+vedremo in \secref{sec:file_open}, permettono di indicare esplicitamente i
+permessi di creazione di un file, ma questo non è possibile per le funzioni
+dell'interfaccia standard ANSI C che non prevede l'esistenza di utenti e
+gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
+permessi non vengono indicati esplicitamente. 
+
+In tutti questi casi l'unico riferimento possibile è quello della modalità di
+apertura del nuovo file (lettura/scrittura o sola lettura), che però può
+fornire un valore che è lo stesso per tutti e tre i permessi di
+\secref{sec:file_perm_overview} (cioè $666$ nel primo caso e $222$ nel
+secondo). Per questo motivo il sistema associa ad ogni processo\footnote{è
+  infatti contenuta nel campo \var{umask} della struttura \struct{fs\_struct},
+  vedi \figref{fig:proc_task_struct}.}  una maschera di bit, la cosiddetta
+\textit{umask}, che viene utilizzata per impedire che alcuni permessi possano
+essere assegnati ai nuovi file in sede di creazione. I bit indicati nella
+maschera vengono infatti cancellati dai permessi quando un nuovo file viene
+creato.
+
+La funzione che permette di impostare il valore di questa maschera di
+controllo è \funcd{umask}, ed il suo prototipo è:
 \begin{prototype}{stat.h}
 {mode\_t umask(mode\_t mask)}
 
@@ -2022,27 +2327,12 @@ Imposta la maschera dei permessi dei bit al valore specificato da \param{mask}
     delle poche funzioni che non restituisce codici di errore.}
 \end{prototype}
 
-Questa maschera è una caratteristica di ogni processo\footnote{è infatti
-  contenuta nel campo \param{umask} di \struct{fs\_struct}, vedi
-  \figref{fig:proc_task_struct}.} e viene utilizzata per impedire che alcuni
-permessi possano essere assegnati ai nuovi file in sede di creazione. I bit
-indicati nella maschera vengono infatti esclusi quando un nuovo file viene
-creato.
-
-In genere questa maschera serve per impostare un valore predefinito dei
-permessi che ne escluda alcuni (usualmente quello di scrittura per il gruppo e
-gli altri, corrispondente ad un valore di $022$). Essa è utile perché le
-routine dell'interfaccia ANSI C degli stream non prevedono l'esistenza dei
-permessi, e pertanto tutti i nuovi file vengono sempre creati con un valore di
-$666$ (cioè permessi di lettura e scrittura per tutti, si veda
-\tabref{tab:file_permission_const} per un confronto); in questo modo è
-possibile cancellare automaticamente i permessi non voluti, senza doverlo fare
-esplicitamente.
-
-In genere il valore di \func{umask} viene stabilito una volta per tutte al
-login a $022$, e di norma gli utenti non hanno motivi per modificarlo. Se però
-si vuole che un processo possa creare un file che chiunque possa leggere
-allora occorrerà cambiare il valore di \func{umask}.
+In genere si usa questa maschera per impostare un valore predefinito che
+escluda preventivamente alcuni permessi (usualmente quello di scrittura per il
+gruppo e gli altri, corrispondente ad un valore per \param{mask} pari a
+$022$).  In questo modo è possibile cancellare automaticamente i permessi non
+voluti.  Di norma questo valore viene impostato una volta per tutte al login a
+$022$, e gli utenti non hanno motivi per modificarlo.
 
 
 \subsection{Le funzioni \func{chown}, \func{fchown} e \func{lchown}}
@@ -2066,7 +2356,7 @@ sono:
   \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
     un errore, in caso di errore \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{EPERM}] L'userid effettivo non corrisponde a quello del
+  \item[\errcode{EPERM}] L'user-ID effettivo non corrisponde a quello del
     proprietario del file o non è zero, o utente e gruppo non sono validi
   \end{errlist}
   Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e
@@ -2133,8 +2423,8 @@ alcun effetto qualora il processo possieda i privilegi di amministratore.
     \acr{s}&\acr{s}&\acr{t}&r&w&x&r&w&x&r&w&x& \\
     \hline
     \hline
-    1&-&-&-&-&-&-&-&-&-&-&-&Se eseguito ha i permessi del propritario\\
-    -&1&-&-&-&1&-&-&-&-&-&-&Se eseguito ha i permessi del gruppo propritario\\
+    1&-&-&-&-&-&-&-&-&-&-&-&Se eseguito ha i permessi del proprietario\\
+    -&1&-&-&-&1&-&-&-&-&-&-&Se eseguito ha i permessi del gruppo proprietario\\
     -&1&-&-&-&0&-&-&-&-&-&-&Il \textit{mandatory locking} è abilitato\\
     -&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato\\
     -&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per il proprietario\\
@@ -2154,12 +2444,12 @@ alcun effetto qualora il processo possieda i privilegi di amministratore.
 \end{table}
 
 Per compattezza, nella tabella si sono specificati i bit di \acr{suid},
-\acr{sgid} e \acr{stiky} con la notazione illustrata anche in
+\acr{sgid} e \acr{sticky} con la notazione illustrata anche in
 \figref{fig:file_perm_bit}. 
 
 In \tabref{tab:file_dirperm_bits} si sono invece riassunti gli effetti dei
 vari bit dei permessi per una directory; anche in questo caso si sono
-specificati i bit di \acr{suid}, \acr{sgid} e \acr{stiky} con la notazione
+specificati i bit di \acr{suid}, \acr{sgid} e \acr{sticky} con la notazione
 compatta illustrata in \figref{fig:file_perm_bit}.
 
 \begin{table}[!htb]
@@ -2205,22 +2495,34 @@ riportato esplicitamente.
 \label{sec:file_chroot}
 
 Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
-\func{chroot} viene usata spesso per restringere le capacità di acccesso di un
+\func{chroot} viene usata spesso per restringere le capacità di accesso di un
 programma ad una sezione limitata del filesystem, per cui ne parleremo in
 questa sezione.
 
 Come accennato in \secref{sec:proc_fork} ogni processo oltre ad una directory
-di lavoro corrente, ha anche una directory radice,\footnote{entrambe sono
-  contenute in due campi di \struct{fs\_struct}, vedi
-  \figref{fig:proc_task_struct}.} che è la directory che per il processo
-costituisce la radice dell'albero dei file e rispetto alla quale vengono
-risolti i pathname assoluti (si ricordi quanto detto in
-\secref{sec:file_organization}). La radice viene eredidata dal padre per ogni
-processo figlio, e quindi di norma coincide con la \file{/} del sistema.
-
-In certe situazioni però per motivi di sicurezza non si vuole che un processo
-possa accedere a tutto il filesystem; per questo si può cambiare la directory
-radice con la funzione \func{chroot}, il cui prototipo è:
+di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe sono
+  contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
+  \struct{fs\_struct}; vedi \figref{fig:proc_task_struct}.} che, pur essendo
+di norma corrispondente alla radice dell'albero di file e directory come visto
+dal kernel (ed illustrato in \secref{sec:file_organization}), ha per il
+processo il significato specifico di directory rispetto alla quale vengono
+risolti i pathname assoluti.\footnote{cioè quando un processo chiede la
+  risoluzione di un pathname, il kernel usa sempre questa directory come punto
+  di partenza.} Il fatto che questo valore sia specificato per ogni processo
+apre allora la possibilità di modificare le modalità di risoluzione dei
+pathname assoluti da parte di un processo cambiando questa directory, così
+come si fa coi pathname relativi cambiando la directory di lavoro.
+
+Normalmente la directory radice di un processo coincide anche con la radice
+del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal
+padre da ogni processo figlio, in generale i processi risolvono i pathname
+assoluti a partire sempre dalla stessa directory, che corrisponde alla
+\file{/} del sistema.
+
+In certe situazioni però, per motivi di sicurezza, è utile poter impedire che
+un processo possa accedere a tutto il filesystem; per far questo si può
+cambiare la sua directory radice con la funzione \funcd{chroot}, il cui
+prototipo è:
 \begin{prototype}{unistd.h}{int chroot(const char *path)}
   Cambia la directory radice del processo a quella specificata da
   \param{path}.
@@ -2228,34 +2530,42 @@ radice con la funzione \func{chroot}, il cui prototipo 
 \bodydesc{La funzione restituisce zero in caso di successo e -1 per
     un errore, in caso di errore \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{EPERM}] L'userid effettivo del processo non è zero.
+  \item[\errcode{EPERM}] L'user-ID effettivo del processo non è zero.
   \end{errlist}
   ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
   \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
   \errval{EROFS} e \errval{EIO}.}
 \end{prototype}
 \noindent in questo modo la directory radice del processo diventerà
-\param{path} (che ovviamente deve esistere) ed ogni pathname assoluto sarà
-risolto a partire da essa, rendendo impossibile accedere alla parte di albero
-sovrastante; si ha cioè quella che viene chiamata una \textit{chroot jail}.
-
-Solo l'amministratore può usare questa funzione, e la nuova radice, per quanto
-detto in \secref{sec:proc_fork}, sarà ereditata da tutti i processi figli. Si
-tenga presente che la funzione non cambia la directory di lavoro corrente, che
-potrebbe restare fuori dalla \textit{chroot jail}.
+\param{path} (che ovviamente deve esistere) ed ogni pathname assoluto usato
+dalle funzioni chiamate nel processo sarà risolto a partire da essa, rendendo
+impossibile accedere alla parte di albero sovrastante.  Si ha così quella che
+viene chiamata una \textit{chroot jail}, in quanto il processo non può più
+accedere a file al di fuori della sezione di albero in cui è stato
+\textsl{imprigionato}.
+
+Solo un processo con i privilegi di amministratore può usare questa funzione,
+e la nuova radice, per quanto detto in \secref{sec:proc_fork}, sarà ereditata
+da tutti i suoi processi figli. Si tenga presente però che la funzione non
+cambia la directory di lavoro, che potrebbe restare fuori dalla \textit{chroot
+  jail}.
 
 Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
-si cedono i privilegi di root. Infatti se in qualche modo il processo ha una
-directory di lavoro corrente fuori dalla \textit{chroot jail}, potrà comunque
-accedere a tutto il filesystem usando pathname relativi.
-
-Ma quando ad un processo restano i privilegi di root esso potrà sempre portare
-la directory di lavoro corrente fuori dalla \textit{chroot jail} creando una
-sottodirectory ed eseguendo una \func{chroot} su di essa. Per questo motivo
-l'uso di questa funzione non ha molto senso quando un processo necessita dei
-privilegi di root per le sue normali operazioni.
-
-Un caso tipico di uso di \func{chroot} è quello di un server ftp anonimo, in
+si cedono i privilegi di root. Infatti se per un qualche motivo il processo
+resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
+comunque accedere a tutto il resto del filesystem usando pathname relativi, i
+quali, partendo dalla directory di lavoro che è fuori della \textit{chroot
+  jail}, potranno (con l'uso di \texttt{..}) risalire fino alla radice
+effettiva del filesystem.
+
+Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
+portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
+trova. Basta infatti creare una nuova \textit{chroot jail} con l'uso di
+\func{chroot} su una qualunque directory contenuta nell'attuale directory di
+lavoro.  Per questo motivo l'uso di questa funzione non ha molto senso quando
+un processo necessita dei privilegi di root per le sue normali operazioni.
+
+Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
 questo caso infatti si vuole che il server veda solo i file che deve
 trasferire, per cui in genere si esegue una \func{chroot} sulla directory che
 contiene i file.  Si tenga presente però che in questo caso occorrerà