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

diff --git a/filedir.tex b/filedir.tex
index 3c564a6..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",
@@ -27,52 +27,56 @@ dei file 
 
 Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like la
 gestione dei file ha delle caratteristiche specifiche che derivano
-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
-standard della gestione dei file in un sistema unix-like, introdotta nel
-capitolo precedente.
+direttamente dall'architettura del sistema. 
+
+In questa sezione esamineremo le funzioni usate per la manipolazione di file e
+directory, per la creazione di link simbolici e diretti, per la gestione e la
+lettura delle directory.
+
+In particolare ci soffermeremo sulle conseguenze che derivano
+dall'architettura dei filesystem illustrata nel capitolo precedente per quanto
+riguarda il comportamento delle varie funzioni.
 
 
 \subsection{Le funzioni \func{link} e \func{unlink}}
 \label{sec:file_link}
 
 Una caratteristica comune a diversi sistemi operativi è quella di poter creare
-dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows) che
-permettono di fare riferimento allo stesso file chiamandolo con nomi diversi
-o accedendovi da directory diverse.
+dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows o i
+nomi logici del VMS) che permettono di fare riferimento allo stesso file
+chiamandolo con nomi diversi o accedendovi da directory diverse.
 
 Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
-usualmente chiamati \textit{link}; ma data la struttura del sistema di
-gestione dei file (ed in particolare quanto trattato in
+usualmente chiamati \textit{link}; ma data l'architettura del sistema riguardo
+la gestione dei file (ed in particolare quanto trattato in
 \secref{sec:file_arch_func}) ci sono due metodi sostanzialmente diversi per
 fare questa operazione.
 
 Come spiegato in \secref{sec:file_filesystem} l'accesso al contenuto di un
-file su disco avviene attraverso il suo inode\index{inode}, e il nome che si
-trova in una directory è solo un'etichetta associata ad un puntatore a che fa
-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\index{inode}; si noti poi
+file su disco avviene passando attraverso il suo inode\index{inode}, che è la
+struttura usata dal kernel che lo identifica univocamente all'interno di un
+singolo filesystem. Il nome del file che si trova nella voce di una directory
+è solo un'etichetta, mantenuta all'interno della directory, che viene
+associata ad un puntatore che fa riferimento al suddetto inode.
+
+Questo significa che, fintanto che si resta sullo stesso filesystem, la
+realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi
+diversi, dati da altrettante diverse associazioni allo stesso
+inode\index{inode} di etichette diverse in directory diverse. Si noti anche
 che nessuno di questi nomi viene ad assumere una particolare preferenza o
-originalità rispetto agli altri.
+originalità rispetto agli altri, in quanto tutti fanno comunque riferimento
+allo stesso inode\index{inode}.
 
-Per aggiungere un nome ad un inode\index{inode} si utilizza la funzione
-\func{link}; si suole chiamare questo tipo di associazione un collegamento
-diretto (o \textit{hard link}).  Il prototipo della funzione e le sue
-caratteristiche principali, come risultano dalla pagina di manuale, sono le
-seguenti:
+Per aggiungere ad una directory una voce che faccia riferimento ad un
+inode\index{inode} già esistente si utilizza la funzione \func{link}; si suole
+chiamare questo tipo di associazione un collegamento diretto (o \textit{hard
+  link}).  Il prototipo della funzione è:
 \begin{prototype}{unistd.h}
 {int link(const char *oldpath, const char *newpath)}
-  Crea un nuovo collegamento diretto al file indicato da \var{oldpath}
-  dandogli nome \var{newpath}.
+  Crea un nuovo collegamento diretto.
   
-  \bodydesc{La funzione restituisce zero in caso di successo e -1 in
-    caso di errore. La variabile \var{errno} viene impostata
-    opportunamente, i principali codici di errore sono:
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+    errore nel qual caso \var{errno} viene impostata ai valori:
   \begin{errlist}
   \item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo
     stesso filesystem.
@@ -89,12 +93,14 @@ seguenti:
   \errval{ENOSPC}, \errval{EIO}.}
 \end{prototype}
 
-La creazione di un nuovo collegamento diretto non copia il contenuto del file,
-ma si limita a creare una voce nella directory specificata con \var{newpath} e
-ad aumentare di uno il numero di riferimenti al file (riportato nel campo
-\var{st\_nlink} della struttura \var{stat}, vedi \secref{sec:file_stat})
-aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
-essere così chiamato con vari nomi in diverse directory.
+La funzione crea sul pathname \param{newpath} un collegamento diretto al file
+indicato da \param{oldpath}.  Per quanto detto la creazione di un nuovo
+collegamento diretto non copia il contenuto del file, ma si limita a creare
+una voce nella directory specificata da \param{newpath} e ad aumentare di uno
+il numero di riferimenti al file (riportato nel campo \var{st\_nlink} della
+struttura \struct{stat}, vedi \secref{sec:file_stat}) aggiungendo il nuovo
+nome ai precedenti. Si noti che uno stesso file può essere così chiamato con
+vari nomi in diverse directory.
  
 Per quanto dicevamo in \secref{sec:file_filesystem} la creazione di un
 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
@@ -106,7 +112,7 @@ La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
 filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
 l'amministratore è in grado di creare un collegamento diretto ad un'altra
 directory: questo viene fatto perché con una tale operazione è possibile
-creare dei circoli nel filesystem (vedi l'esempio mostrato in
+creare dei \textit{loop} 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
 complicata (in genere per questo tipo di errori occorre far girare il
@@ -119,41 +125,48 @@ disabilitata, e al tentativo di creare un link diretto ad una directory la
 funzione restituisce l'errore \errcode{EPERM}.
 
 La rimozione di un file (o più precisamente della voce che lo referenzia
-all'interno di una directory) si effettua con la funzione \func{unlink}; il
+all'interno di una directory) si effettua con la funzione \funcd{unlink}; il
 suo prototipo è il seguente:
 \begin{prototype}{unistd.h}{int unlink(const char *pathname)}
-  Cancella il nome specificato dal pathname nella relativa directory e
-  decrementa il numero di riferimenti nel relativo inode\index{inode}. Nel
-  caso di link simbolico cancella il link simbolico; nel caso di
-  socket\index{socket}, fifo o file di dispositivo\index{file!di dispositivo}
-  rimuove il nome, ma come per i file i processi che hanno aperto uno di
-  questi oggetti possono continuare ad utilizzarlo.
+
+  Cancella un file.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso il file non viene toccato. La variabile
     \var{errno} viene impostata secondo i seguenti codici di errore:
   \begin{errlist}
-  \item[\errcode{EISDIR}] \var{pathname} si riferisce ad una directory
-    (valore specifico ritornato da Linux che non consente l'uso di
-    \var{unlink} con le directory, e non conforme allo standard POSIX, che
-    prescrive invece l'uso di \errcode{EPERM} in caso l'operazione non sia
-    consentita o il processo non abbia privilegi sufficienti).
-  \item[\errcode{EROFS}] \var{pathname} è su un filesystem montato in sola
+  \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una directory.
+    \footnotemark
+  \item[\errcode{EROFS}] \param{pathname} è su un filesystem montato in sola
   lettura.
-  \item[\errcode{EISDIR}] \var{pathname} fa riferimento a una directory.
+  \item[\errcode{EISDIR}] \param{pathname} fa riferimento a una directory.
   \end{errlist}
   ed inoltre: \errval{EACCES}, \errval{EFAULT}, \errval{ENOENT},
   \errval{ENOTDIR}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP},
   \errval{EIO}.}
 \end{prototype}
 
+\footnotetext{questo è un valore specifico ritornato da Linux che non consente
+  l'uso di \func{unlink} con le directory (vedi \secref{sec:file_remove}). Non
+  è conforme allo standard POSIX, che prescrive invece l'uso di
+  \errcode{EPERM} in caso l'operazione non sia consentita o il processo non
+  abbia privilegi sufficienti.}
+
+La funzione cancella il nome specificato da \param{pathname} nella relativa
+directory e decrementa il numero di riferimenti nel relativo
+inode\index{inode}. Nel caso di link simbolico cancella il link simbolico; nel
+caso di socket\index{socket}, fifo o file di dispositivo\index{file!di
+  dispositivo} rimuove il nome, ma come per i file i processi che hanno aperto
+uno di questi oggetti possono continuare ad utilizzarlo.
+
 Per cancellare una voce in una directory è necessario avere il permesso di
-scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
-il diritto di esecuzione sulla directory che la contiene (torneremo in
-dettaglio sui permessi e gli attributi in \secref{sec:file_access_control}),
-se inoltre lo \textit{sticky} bit è impostato occorrerà anche essere
-proprietari del file o proprietari della directory (o root, per cui nessuna
-delle restrizioni è applicata).
+scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
+il diritto di esecuzione sulla directory che la contiene (affronteremo in
+dettaglio l'argomento dei permessi di file e directory in
+\secref{sec:file_access_control}). Se inoltre lo \textit{sticky} bit (vedi
+\secref{sec:file_sticky}) è impostato occorrerà anche essere proprietari del
+file o proprietari della directory (o root, per cui nessuna delle restrizioni
+è applicata).
 
 Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
 nome dalla directory e l'incremento/decremento del numero di riferimenti
@@ -162,11 +175,18 @@ nell'inode\index{inode} devono essere effettuati in maniera atomica (si veda
 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
+Si ricordi infine che un file non viene eliminato dal disco fintanto che tutti
 i riferimenti ad esso sono stati cancellati: solo quando il \textit{link
-  count} mantenuto nell'inode\index{inode} diventa zero lo spazio occupato
-viene rimosso. A questo però si aggiunge un'altra condizione, e cioè che non
-ci siano processi che abbiano detto file aperto.
+  count} mantenuto nell'inode\index{inode} diventa zero lo spazio occupato su
+disco viene rimosso (si ricordi comunque che a questo si aggiunge sempre
+un'ulteriore condizione,\footnote{come vedremo in
+  \secref{cha:file_unix_interface} il kernel mantiene anche una tabella dei
+  file aperti nei vari processi, che a sua volta contiene i riferimenti agli
+  inode ad essi relativi. Prima di procedere alla cancellazione dello spazio
+  occupato su disco dal contenuto di un file il kernel controlla anche questa
+  tabella, per verificare che anche in essa non ci sia più nessun riferimento
+  all'inode in questione.} e cioè che non ci siano processi che abbiano il
+suddetto file aperto).
 
 Questa proprietà viene spesso usata per essere sicuri di non lasciare file
 temporanei su disco in caso di crash dei programmi; la tecnica è quella di
@@ -184,49 +204,59 @@ processo (quando tutti i file vengono chiusi).
 Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
 \func{unlink} sulle directory; per cancellare una directory si può usare la
 funzione \func{rmdir} (vedi \secref{sec:file_dir_creat_rem}), oppure la
-funzione \func{remove}. Questa è la funzione prevista dallo standard ANSI C
-per cancellare un file o una directory (e funziona anche per i sistemi che non
-supportano i link diretti). Per i file è identica a \func{unlink} e per le
-directory è identica a \func{rmdir}:
+funzione \funcd{remove}. 
+
+Questa è la funzione prevista dallo standard ANSI C per cancellare un file o
+una directory (e funziona anche per i sistemi che non supportano i link
+diretti). Per i file è identica a \func{unlink} e per le directory è identica
+a \func{rmdir}; il suo prototipo è:
 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
-  Cancella un nome dal filesystem. Usa \func{unlink} per i file e
-  \func{rmdir} per le directory.
+  Cancella un nome dal filesystem. 
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso il file non viene toccato. Per i codici di
-    errore vedi quanto riportato nelle descrizioni di \func{unlink} e
-    \func{rmdir}.}
+    errore, nel qual caso il file non viene toccato.
+    
+    I codici di errore riportati in \var{errno} sono quelli della chiamata
+    utilizzata, pertanto si può fare riferimento a quanto illustrato nelle
+    descrizioni di \func{unlink} e \func{rmdir}.}
 \end{prototype}
 
+La funzione utilizza la funzione \func{unlink}\footnote{questo vale usando le
+  \acr{glibc}; nelle libc4 e nelle libc5 la funzione \func{remove} è un
+  semplice alias alla funzione \func{unlink} e quindi non può essere usata per
+  le directory.} per cancellare i file e la funzione \func{rmdir} per
+cancellare le directory; si tenga presente che per alcune implementazioni del
+protocollo NFS utilizzare questa funzione può comportare la scomparsa di file
+ancora in uso.
+
 Per cambiare nome ad un file o a una directory (che devono comunque essere
-nello stesso filesystem) si usa invece la funzione \func{rename},\footnote{la
-  funzione è definita dallo standard ANSI C solo per i file, POSIX estende la
-  funzione anche alle directory.} il cui prototipo è:
+nello stesso filesystem) si usa invece la funzione \funcd{rename},\footnote{la
+  funzione è definita dallo standard ANSI C, ma si applica solo per i file, lo
+  standard POSIX estende la funzione anche alle directory.} il cui prototipo
+è:
 \begin{prototype}{stdio.h}
   {int rename(const char *oldpath, const char *newpath)} 
   
-  Rinomina \var{oldpath} in \var{newpath}, eseguendo se necessario lo
-  spostamento di un file fra directory diverse. Eventuali altri link diretti
-  allo stesso file non vengono influenzati.
+  Rinomina un file.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso il file non viene toccato. La variabile
     \var{errno} viene impostata secondo i seguenti codici di errore:
   \begin{errlist} 
-  \item[\errcode{EISDIR}] \var{newpath} è una directory mentre \var{oldpath}
-    non è una directory.
-  \item[\errcode{EXDEV}] \var{oldpath} e \var{newpath} non sono sullo stesso
-    filesystem.
-  \item[\errcode{ENOTEMPTY}] \var{newpath} è una directory già esistente e non
-    vuota.
-  \item[\errcode{EBUSY}] o \var{oldpath} o \var{newpath} sono in uso da parte
-    di qualche processo (come directory di lavoro o come radice) o del sistema
-    (come mount point).
-  \item[\errcode{EINVAL}] \var{newpath} contiene un prefisso di \var{oldpath} o
-    più in generale si è cercato di creare una directory come sottodirectory
-    di se stessa.
+  \item[\errcode{EISDIR}] \param{newpath} è una directory mentre
+    \param{oldpath} non è una directory.
+  \item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo
+    stesso filesystem.
+  \item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
+    non vuota.
+  \item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
+    parte di qualche processo (come directory di lavoro o come radice) o del
+    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
+    sotto-directory di se stessa.
   \item[\errcode{ENOTDIR}] Uno dei componenti dei pathname non è una directory
-    o \var{oldpath} è una directory e \var{newpath} esiste e non è una
+    o \param{oldpath} è una directory e \param{newpath} esiste e non è una
     directory.
   \end{errlist} 
   ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
@@ -234,25 +264,29 @@ nello stesso filesystem) si usa invece la funzione \func{rename},\footnote{la
   \errval{ENOSPC}.}
 \end{prototype}
 
+La funzione rinomina il file \param{oldpath} in \param{newpath}, eseguendo se
+necessario lo spostamento di un file fra directory diverse. Eventuali altri
+link diretti allo stesso file non vengono influenzati.
+
 Il comportamento della funzione è diverso a seconda che si voglia rinominare
-un file o una directory; se ci riferisce a un file allora \var{newpath}, se
+un file o una directory; se ci riferisce a un file allora \param{newpath}, se
 esiste, non deve essere una directory (altrimenti si ha l'errore
-\errcode{EISDIR}). Nel caso \var{newpath} indichi un file esistente questo
+\errcode{EISDIR}). Nel caso \param{newpath} indichi un file esistente questo
 viene cancellato e rimpiazzato (atomicamente).
 
-Se \var{oldpath} è una directory allora \var{newpath}, se esiste, deve essere
-una directory vuota, altrimenti si avranno gli errori \errcode{ENOTDIR} (se
-non è una directory) o \errcode{ENOTEMPTY} (se non è vuota). Chiaramente
-\var{newpath} non può contenere \var{oldpath} altrimenti si avrà un errore
+Se \param{oldpath} è una directory allora \param{newpath}, se esiste, deve
+essere una directory vuota, altrimenti si avranno gli errori \errcode{ENOTDIR}
+(se non è una directory) o \errcode{ENOTEMPTY} (se non è vuota). Chiaramente
+\param{newpath} non può contenere \param{oldpath} altrimenti si avrà un errore
 \errcode{EINVAL}.
 
-Se \var{oldpath} si riferisce a un link simbolico questo sarà rinominato; se
-\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 \textit{glibc}, il comportamento più ragionevole
-sarebbe quello di cancellare \var{oldpath}.
+Se \param{oldpath} si riferisce a un link simbolico questo sarà rinominato; se
+\param{newpath} è un link simbolico verrà cancellato come qualunque altro
+file.  Infine qualora \param{oldpath} e \param{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 \textit{glibc}, il comportamento più
+ragionevole sarebbe quello di cancellare \param{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
@@ -261,10 +295,10 @@ entrambi i nomi dello stesso file, o, in caso di sostituzione di un file
 esistente, non trovare quest'ultimo prima che la sostituzione sia stata
 eseguita.
 
-In ogni caso se \var{newpath} esiste e l'operazione fallisce per un qualche
+In ogni caso se \param{newpath} esiste e l'operazione fallisce per un qualche
 motivo (come un crash del kernel), \func{rename} garantisce di lasciare
-presente un'istanza di \var{newpath}. Tuttavia nella sovrascrittura potrà
-esistere una finestra in cui sia \var{oldpath} che \var{newpath} fanno
+presente un'istanza di \param{newpath}. Tuttavia nella sovrascrittura potrà
+esistere una finestra in cui sia \param{oldpath} che \param{newpath} fanno
 riferimento allo stesso file.
 
 
@@ -285,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 è
-\func{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 è
@@ -362,21 +399,21 @@ 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
 alle informazioni del link invece che a quelle del file a cui esso fa
 riferimento. Quando si vuole leggere il contenuto di un link simbolico si usa
-la funzione \func{readlink}, il cui prototipo è:
+la funzione \funcd{readlink}, il cui prototipo è:
 \begin{prototype}{unistd.h}
 {int readlink(const char *path, char *buff, size\_t size)} 
-  Legge il contenuto del link simbolico indicato da \var{path} nel buffer
-  \var{buff} di dimensione \var{size}.
+  Legge il contenuto del link simbolico indicato da \param{path} nel buffer
+  \param{buff} di dimensione \param{size}.
   
   \bodydesc{La funzione restituisce il numero di caratteri letti dentro
-    \var{buff} o -1 per un errore, nel qual caso la variabile
+    \param{buff} o -1 per un errore, nel qual caso la variabile
     \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{EINVAL}] \param{path} non è un link simbolico o \param{size}
@@ -390,7 +427,7 @@ la funzione \func{readlink}, il cui prototipo 
 La funzione apre il link simbolico, ne legge il contenuto, lo scrive nel
 buffer, e lo richiude. Si tenga presente che la funzione non termina la
 stringa con un carattere nullo e la tronca alla dimensione specificata da
-\var{size} per evitare di sovrascrivere oltre le dimensioni del buffer.
+\param{size} per evitare di sovrascrivere oltre le dimensioni del buffer.
 
 
 \begin{figure}[htb]
@@ -404,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
@@ -445,15 +483,18 @@ ci mostrerebbe invece l'esistenza di \file{temporaneo}.
 \subsection{La creazione e la cancellazione delle directory} 
 \label{sec:file_dir_creat_rem}
 
-Per creare e cancellare delle directory si usano le due funzioni (omonime
-degli analoghi comandi di shell) \func{mkdir} e \func{rmdir}.  Per poter
-accedere ai tipi usati da queste funzioni si deve includere il file
-\file{sys/types.h}, il prototipo della prima è:
-\begin{prototype}{sys/stat.h}
-  {int mkdir(const char *dirname, mode\_t mode)} 
-  Crea una nuova directory vuota con il nome indicato da \var{dirname},
-  assegnandole i permessi indicati da \var{mode}. Il nome può essere indicato
-  con il pathname assoluto o relativo.
+Benché in sostanza le directory non siano altro che dei file contenenti
+elenchi di nomi ed inode, non è possibile trattarle come file ordinari e
+devono essere create direttamente dal kernel attraverso una opportuna system
+call.\footnote{questo permette anche, attraverso l'uso del VFS, l'utilizzo di
+  diversi formati per la gestione dei suddetti elenchi.}  La funzione usata
+per creare una directory è \funcd{mkdir}, ed il suo prototipo è:
+\begin{functions}
+  \headdecl{sys/stat.h}
+  \headdecl{sys/types.h}
+  \funcdecl{int mkdir(const char *dirname, mode\_t mode)} 
+
+  Crea una nuova directory.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} assumerà i valori:
@@ -475,34 +516,36 @@ accedere ai tipi usati da queste funzioni si deve includere il file
   ed inoltre anche \errval{EPERM}, \errval{EFAULT}, \errval{ENAMETOOLONG},
   \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP},
   \errval{EROFS}.}
-\end{prototype}
+\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
+\param{dirname}. Il nome può essere indicato sia come pathname assoluto che
+relativo.
 
-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
-valori sono riportati in \tabref{tab:file_permission_const}) sono modificati
-dalla maschera di creazione dei file (si veda \secref{sec:file_umask}).  La
-titolarità della nuova directory è impostata secondo quanto riportato in
+I permessi di accesso alla directory (vedi \secref{sec:file_access_control})
+sono specificati da \param{mode}, i cui possibili valori sono riportati in
+\tabref{tab:file_permission_const}; questi sono modificati dalla maschera di
+creazione dei file (si veda \secref{sec:file_umask}).  La titolarità della
+nuova directory è impostata secondo quanto riportato in
 \secref{sec:file_ownership}.
 
-La seconda funzione serve ad eliminare una directory già vuota (la directory
-deve cioè contenere soltanto le due voci standard \file{.} e \file{..}); il
-suo prototipo è:
+La funzione per la cancellazione di una directory è \funcd{rmdir}, il suo
+prototipo è:
 \begin{prototype}{sys/stat.h}{int rmdir(const char *dirname)} 
-  Cancella la directory \var{dirname}, che deve essere vuota.  Il nome può
-  essere indicato con il pathname assoluto o relativo.
-  
+  Cancella una directory.
+
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
   \item[\errcode{EPERM}] Il filesystem non supporta la cancellazione di
-    directory, oppure la directory che contiene \var{dirname} ha lo sticky bit
-    impostato e l'userid effettivo del processo non corrisponde al
+    directory, oppure la directory che contiene \param{dirname} ha lo sticky
+    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
     di attraversare (esecuzione) una delle directory specificate in
-    \var{dirname}.
+    \param{dirname}.
   \item[\errcode{EBUSY}] La directory specificata è la directory di lavoro o la
     radice di qualche processo.
   \item[\errcode{ENOTEMPTY}] La directory non è vuota.
@@ -511,6 +554,10 @@ suo prototipo 
   \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP}, \errval{EROFS}.}
 \end{prototype}
 
+La funzione cancella la directory \param{dirname}, che deve essere vuota (la
+directory deve cioè contenere soltanto le due voci standard \file{.} e
+\file{..}).  Il nome può essere indicato con il pathname assoluto o relativo.
+
 La modalità con cui avviene la cancellazione è analoga a quella di
 \func{unlink}: fintanto che il numero di link all'inode\index{inode} della
 directory non diventa nullo e nessun processo ha la directory aperta lo spazio
@@ -533,14 +580,15 @@ vedremo in \capref{cha:socket_intro}).
 La manipolazione delle caratteristiche di questi file e la loro cancellazione
 può essere effettuata con le stesse funzioni che operano sui file regolari; ma
 quando li si devono creare sono necessarie delle funzioni apposite. La prima
-di queste funzioni è \func{mknod}, il suo prototipo è:
+di queste funzioni è \funcd{mknod}, il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/stat.h}
   \headdecl{fnctl.h}
   \headdecl{unistd.h}
-  \funcdecl{int mknod(const char *pathname, mode\_t mode, dev\_t dev)} Crea un
-  inode, si usa per creare i file speciali.
+  \funcdecl{int mknod(const char *pathname, mode\_t mode, dev\_t dev)} 
+  
+  Crea un inode, si usa per creare i file speciali.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} assumerà i valori:
@@ -548,8 +596,8 @@ di queste funzioni 
   \item[\errcode{EPERM}] Non si hanno privilegi sufficienti a creare l'inode, o
     il filesystem su cui si è cercato di creare \func{pathname} non supporta
     l'operazione.
-  \item[\errcode{EINVAL}] Il valore di \var{mode} non indica un file, una fifo
-    o un dipositivo.
+  \item[\errcode{EINVAL}] Il valore di \param{mode} non indica un file, una
+    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},
@@ -585,51 +633,417 @@ creare l'inode\index{inode}.
 
 Per creare una fifo (un file speciale, su cui torneremo in dettaglio in
 \secref{sec:ipc_named_pipe}) lo standard POSIX specifica l'uso della funzione
-\func{mkfifo}, il cui prototipo è:
+\funcd{mkfifo}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{sys/stat.h} 
   
-  \funcdecl{int mkfifo(const char *pathname, mode\_t mode)} Crea una fifo.
+  \funcdecl{int mkfifo(const char *pathname, mode\_t mode)} 
+  
+  Crea una fifo.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} assumerà i valori \errval{EACCES},
     \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
-ovviamente senso aprirle come fossero dei file di dati. 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
-in una directory (onde evitare inconsistenze all'interno del filesystem), i
-processi devono creare i file usando le apposite funzioni.
+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 *dirname)} 
+  
+  Apre un \textit{directory stream}.
+  
+  \bodydesc{La funzione restituisce un puntatore al \textit{directory stream}
+    in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
+    assumerà i valori \errval{EACCES}, \errval{EMFILE}, \errval{ENFILE},
+    \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}.}
+\end{functions}
+
+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ò 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} 
+  
+  \funcdecl{int dirfd(DIR * dir)} 
+  
+  Restituisce il file descriptor associato ad un \textit{directory stream}.
+  
+  \bodydesc{La funzione restituisce il file descriptor (un valore positivo) in
+    caso di successo e -1 in caso di errore.}
+\end{functions}
+
+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 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
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/dirent.c}
+  \end{minipage} 
+  \normalsize 
+  \caption{La struttura \structd{dirent} per la lettura delle informazioni dei 
+    file.}
+  \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}.  
 
-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 \func{opendir} apre uno di
-questi stream e 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 \var{struct dirent}.
+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}
 
-(NdA Il resto va scritto!!! É noioso e lo farò più avanti).
+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
@@ -640,20 +1054,18 @@ 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 \var{buffer}, che deve essere precedentemente
-  allocata, per una dimensione massima di \var{size}.
+  Legge il pathname della directory di lavoro corrente.
   
-  \bodydesc{La funzione restituisce il puntatore \var{buffer} se riesce,
+  \bodydesc{La funzione restituisce il puntatore \param{buffer} se riesce,
     \val{NULL} se fallisce, in quest'ultimo caso la variabile
     \var{errno} è impostata con i seguenti codici di errore:
   \begin{errlist}
-  \item[\errcode{EINVAL}] L'argomento \var{size} è zero e \var{buffer} non
+  \item[\errcode{EINVAL}] L'argomento \param{size} è zero e \param{buffer} non
     è nullo.
-  \item[\errcode{ERANGE}] L'argomento \var{size} è più piccolo della
+  \item[\errcode{ERANGE}] L'argomento \param{size} è più piccolo della
     lunghezza del pathname. 
   \item[\errcode{EACCES}] Manca il permesso di lettura o di ricerca su uno dei
     componenti del pathname (cioè su una delle directory superiori alla
@@ -661,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 \var{size} la funzione restituisce un errore.  Si
-può anche specificare un puntatore nullo come \var{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 \var{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
@@ -688,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:
@@ -708,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.
@@ -734,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. 
@@ -757,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
@@ -793,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.
   
@@ -816,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
@@ -836,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)}
@@ -855,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}
@@ -871,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}.
@@ -909,25 +1324,26 @@ gestione del controllo di accesso, trattate in in
 \label{sec:file_stat}
 
 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
-delle funzioni \func{stat}; questa è la funzione che ad esempio usa il comando
-\cmd{ls} per poter ottenere e mostrare tutti i dati dei files. I prototipi di
-queste funzioni sono i seguenti:
+delle funzioni \func{stat} (\funcd{stat}, \funcd{fstat} e \funcd{lstat});
+questa è la funzione che ad esempio usa il comando \cmd{ls} per poter ottenere
+e mostrare tutti i dati dei files. I prototipi di queste funzioni sono i
+seguenti:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/stat.h} 
   \headdecl{unistd.h}
 
   \funcdecl{int stat(const char *file\_name, struct stat *buf)} Legge le
-  informazione del file specificato da \var{file\_name} e le inserisce in
-  \var{buf}.
+  informazione del file specificato da \param{file\_name} e le inserisce in
+  \param{buf}.
   
   \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
-  \func{stat} eccetto che se il \var{file\_name} è un link simbolico vengono
-  lette le informazioni relativa ad esso e non al file a cui fa riferimento.
+  \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
+  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
-  descriptor \var{filedes}.
+  descriptor \param{filedes}.
   
   \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
     errore, nel qual caso \var{errno} assumerà uno dei valori: \errval{EBADF},
@@ -937,7 +1353,7 @@ queste funzioni sono i seguenti:
 \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} usata da queste funzioni è definita nell'header
+La struttura \struct{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 \figref{fig:file_stat_struct}, così come
 riportata dalla pagina di manuale di \func{stat} (in realtà la definizione
@@ -948,27 +1364,11 @@ 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 \var{stat} per la lettura delle informazioni dei 
-    file}
+  \caption{La struttura \structd{stat} per la lettura delle informazioni dei 
+    file.}
   \label{fig:file_stat_struct}
 \end{figure}
 
@@ -983,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,
@@ -1032,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      \\ 
@@ -1069,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.
 
@@ -1079,7 +1477,7 @@ poi si effettua il confronto con la combinazione di tipi scelta.
 \subsection{Le dimensioni dei file}
 \label{sec:file_file_size}
 
-Il membro \var{st\_size} contiene la dimensione del file in byte (se si tratta
+Il campo \var{st\_size} contiene la dimensione del file in byte (se si tratta
 di un file regolare, nel caso di un link simbolico la dimensione è quella del
 pathname che contiene, per le fifo è sempre nullo).
 
@@ -1110,23 +1508,23 @@ presenti al di l
 
 Un file può sempre essere troncato a zero aprendolo con il flag
 \const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
-dimensione si possono usare le due funzioni \func{truncate} e
-\func{ftruncate}, i cui prototipi sono:
+dimensione si possono usare le due funzioni \funcd{truncate} e
+\funcd{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
-    un valore massimo specificato da \var{lenght}. 
+    length)} Fa si che la dimensione del file \param{file\_name} sia troncata
+  ad un valore massimo specificato da \param{lenght}.
   
   \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate}
   eccetto che si usa con un file aperto, specificato tramite il suo file
-  descriptor \var{fd}.
+  descriptor \param{fd}.
   
   \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} viene impostata opportunamente; per
     \func{ftruncate} si hanno i valori:
   \begin{errlist}
-  \item[\errcode{EBADF}] \var{fd}  non è un file descriptor.
-  \item[\errcode{EINVAL}] \var{fd} è un riferimento ad un
+  \item[\errcode{EBADF}] \param{fd}  non è un file descriptor.
+  \item[\errcode{EINVAL}] \param{fd} è un riferimento ad un
     socket\index{socket}, non a un file o non è aperto in scrittura.
   \end{errlist}
   per \func{truncate} si hanno:
@@ -1152,8 +1550,8 @@ zeri (e in genere si ha la creazione di un \textit{hole} nel file).
 Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
 nell'inode\index{inode} insieme agli altri attributi del file e possono essere
 letti tramite la funzione \func{stat}, che li restituisce attraverso tre campi
-della struttura \var{stat} di \figref{fig:file_stat_struct}. Il significato di
-detti tempi e dei relativi campi è riportato nello schema in
+della struttura \struct{stat} di \figref{fig:file_stat_struct}. Il significato
+di detti tempi e dei relativi campi è riportato nello schema in
 \tabref{tab:file_file_times}, dove è anche riportato un esempio delle funzioni
 che effettuano cambiamenti su di essi.
 
@@ -1298,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)} 
 
@@ -1313,24 +1711,20 @@ di \param{times}. Se questa 
   \item[\errcode{ENOENT}] \param{filename} non esiste.
   \end{errlist}}
 \end{prototype}
- 
-La funzione prende come argomento \param{times} una struttura \var{utimebuf},
-la cui definizione è riportata in \figref{fig:struct_utimebuf}, con la quale
-si possono specificare i nuovi valori che si vogliono impostare per tempi.
+
+La funzione prende come argomento \param{times} una struttura
+\struct{utimebuf}, la cui definizione è riportata in
+\figref{fig:struct_utimebuf}, con la quale si possono specificare i nuovi
+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 \type{utimbuf}, usata da \func{utime} per modificare i
-    tempi dei file.} 
+  \caption{La struttura \structd{utimbuf}, usata da \func{utime} per modificare
+    i tempi dei file.}
   \label{fig:struct_utimebuf}
 \end{figure}
 
@@ -1359,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.
 
@@ -1371,12 +1765,12 @@ Ad ogni file Linux associa sempre l'utente che ne 
 cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
 degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori
 sono accessibili da programma tramite la funzione \func{stat}, e sono
-mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura \var{stat}
-(si veda \secref{sec:file_stat}).\footnote{Questo è vero solo per filesystem
-  di tipo Unix, ad esempio non è vero per il filesystem vfat di Windows, che
-  non fornisce nessun supporto per l'accesso multiutente, e per il quale i
-  permessi vengono assegnati in maniera fissa con un opzione in fase di
-  montaggio.}
+mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura
+\struct{stat} (si veda \secref{sec:file_stat}).\footnote{Questo è vero solo
+  per filesystem di tipo Unix, ad esempio non è vero per il filesystem vfat di
+  Windows, che non fornisce nessun supporto per l'accesso multiutente, e per
+  il quale i permessi vengono assegnati in maniera fissa con un opzione in
+  fase di montaggio.}
 
 Il controllo di accesso ai file segue un modello abbastanza semplice che
 prevede tre permessi fondamentali strutturati su tre livelli di accesso.
@@ -1408,23 +1802,23 @@ 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}
   \caption{Lo schema dei bit utilizzati per specificare i permessi di un file
-    contenuti nel campo \var{st\_mode} di \var{fstat}.}
+    contenuti nel campo \var{st\_mode} di \struct{fstat}.}
   \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 \func{stat} (si veda di
+alcuni bit del campo \var{st\_mode} della struttura \struct{stat} (si veda di
 nuovo \figref{fig:file_stat_struct}).
 
 In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
@@ -1476,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}
@@ -1512,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,
@@ -1522,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*}
@@ -1544,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, 
@@ -1567,7 +1962,7 @@ tutti gli altri non vengono controllati.
 \label{sec:file_suid_sgid}
 
 Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del
-campo \var{st\_mode} di \var{stat} che vengono usati per il controllo di
+campo \var{st\_mode} di \struct{stat} che vengono usati per il controllo di
 accesso oltre ai bit dei permessi veri e propri, ci sono altri tre bit che
 vengono usati per indicare alcune proprietà speciali dei file.  Due di questi
 sono i bit detti \acr{suid} (da \textit{set-user-ID bit}) e \acr{sgid} (da
@@ -1578,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
@@ -1661,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}
@@ -1679,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*}
@@ -1699,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}
@@ -1739,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 \var{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
@@ -1759,7 +2157,7 @@ contrario (o di errore) ritorna -1.
   \footnotesize
   \begin{tabular}{|c|l|}
     \hline
-    \textbf{\var{mode}} & \textbf{Significato} \\
+    \textbf{\param{mode}} & \textbf{Significato} \\
     \hline
     \hline
     \const{R\_OK} & verifica il permesso di lettura \\
@@ -1768,7 +2166,7 @@ contrario (o di errore) ritorna -1.
     \const{F\_OK} & verifica l'esistenza del file \\
     \hline
   \end{tabular}
-  \caption{Valori possibile per il parametro \var{mode} della funzione 
+  \caption{Valori possibile per l'argomento \param{mode} della funzione 
     \func{access}.}
   \label{tab:file_access_mode_val}
 \end{table}
@@ -1783,22 +2181,22 @@ permessi per accedere ad un certo file.
 \label{sec:file_chmod}
 
 Per cambiare i permessi di un file il sistema mette ad disposizione due
-funzioni \func{chmod} e \func{fchmod}, che operano rispettivamente su un
+funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
 filename e su un file descriptor, i loro prototipi sono:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/stat.h} 
   
   \funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del
-  file indicato da \var{path} al valore indicato da \var{mode}.
+  file indicato da \param{path} al valore indicato da \param{mode}.
   
   \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa
-  il file descriptor \var{fd} per indicare il file.
+  il file descriptor \param{fd} per indicare il file.
   
   \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}
@@ -1817,7 +2215,7 @@ file.
   \footnotesize
   \begin{tabular}[c]{|c|c|l|}
     \hline
-    \textbf{\var{mode}} & \textbf{Valore} & \textbf{Significato} \\
+    \textbf{\param{mode}} & \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
     \const{S\_ISUID} & 04000 & set user ID \\
@@ -1861,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}.
 
@@ -1871,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
@@ -1881,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
@@ -1896,40 +2294,45 @@ 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)}
 
-  Imposta la maschera dei permessi dei bit al valore specificato da \var{mask}
-  (di cui vengono presi solo i 9 bit meno significativi).
+Imposta la maschera dei permessi dei bit al valore specificato da \param{mask}
+(di cui vengono presi solo i 9 bit meno significativi).
   
   \bodydesc{La funzione ritorna il precedente valore della maschera. È una
     delle poche funzioni che non restituisce codici di errore.}
 \end{prototype}
 
-Questa maschera è una caratteristica di ogni processo\footnote{è infatti
-  contenuta nel campo \var{umask} di \var{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}}
@@ -1937,7 +2340,8 @@ allora occorrer
 
 Come per i permessi, il sistema fornisce anche delle funzioni che permettano
 di cambiare utente e gruppo cui il file appartiene; le funzioni in questione
-sono tre e i loro prototipi sono i seguenti:
+sono tre: \funcd{chown}, \funcd{fchown} e \funcd{lchown}, ed i loro prototipi
+sono:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/stat.h} 
@@ -1947,12 +2351,12 @@ sono tre e i loro prototipi sono i seguenti:
   \funcdecl{int lchown(const char *path, uid\_t owner, gid\_t group)}
 
   Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
-  specificati dalle variabili \var{owner} e \var{group}. 
+  specificati dalle variabili \param{owner} e \param{group}. 
   
   \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
@@ -1976,7 +2380,7 @@ un link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
   \func{chown} che seguisse i link simbolici.} La funzione \func{fchown} opera
 su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
 Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
-valore per \var{owner} e \var{group} i valori restano immutati.
+valore per \param{owner} e \param{group} i valori restano immutati.
 
 Quando queste funzioni sono chiamate con successo da un processo senza i
 privilegi di root entrambi i bit \acr{suid} e \acr{sgid} vengono
@@ -2019,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\\
@@ -2040,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]
@@ -2091,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 \var{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}.
@@ -2114,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à