X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=4eda60ba3d69343cc958fa638fc20f6d64501015;hp=3a371a4b6c4766c6df9fe6769d139a9b7df83fc2;hb=76b2e33478d2b32d569c72b25924d5d336c1b8ca;hpb=743ef11e68d40acfca27b95a3438b4cec6c59a8a

diff --git a/filedir.tex b/filedir.tex
index 3a371a4..4eda60b 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -526,7 +526,7 @@ il filesystem più diffuso, ed una serie di ulteriori miglioramenti con il
 successivo \acr{ext4}. In futuro è previsto che questo debba essere sostituito
 da un filesystem completamente diverso, \acr{btrfs}, che dovrebbe diventare il
 filesystem standard di Linux, ma questo al momento è ancora in fase di
-sviluppo.\footnote{si fa riferimento al momento dell'ultima revisione di di
+sviluppo.\footnote{si fa riferimento al momento dell'ultima revisione di
   questo paragrafo, l'inizio del 2012.}
 
 Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
@@ -712,8 +712,8 @@ del comando \texttt{mount}. I valori utilizzabili dipendono dal tipo di
 filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della
 pagina di manuale di questo comando e dei singoli filesystem.
 
-Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
-disponibile nella directory specificata come \textit{mount point}, il
+Dopo l'esecuzione della funzione il contenuto del filesystem viene reso
+disponibile nella directory specificata come \textit{mount point} ed il
 precedente contenuto di detta directory viene mascherato dal contenuto della
 directory radice del filesystem montato. Fino ai kernel della serie 2.2.x non
 era possibile montare un filesystem se un \textit{mount point} era già in uso,
@@ -725,12 +725,12 @@ visibile, mascherando quelli sottostanti.
 In realtà quella di montare un filesystem è solo una delle operazioni che si
 possono effettuare con \func{mount}, la funzione infatti è dedicata a tutte le
 operazioni relative alla gestione del montaggio dei filesystem e dei
-\textit{mount-point}. Ad esempio fin dalle sue origini poteva essere
+\textit{mount point}. Ad esempio fin dalle sue origini poteva essere
 utilizzata per effettuare il rimontaggio di un filesystem con opzioni diverse,
 ed a partire dal kernel 2.4.x è divenuto possibile usarla per spostare
 atomicamente un \textit{mount point} da una directory ad un'altra, per montare
 lo stesso filesystem in diversi \textit{mount point}, per montare una
-directory su un'altra (il cosiddetto \textit{bind-mount}).
+directory su un'altra (il cosiddetto \textit{bind mount}).
 
 \itindend{mount~point}
 
@@ -760,17 +760,17 @@ Come accennato il tipo di operazione eseguito da \func{mount} viene stabilito
 in base al contenuto di \param{mountflags}, la scelta viene effettuata
 controllando nell'ordine:
 \begin{enumerate*}
-\item se è presente il flag \const{MS\_REMOUNT} nel qual caso verrà eseguito
+\item se è presente il flag \const{MS\_REMOUNT}, nel qual caso verrà eseguito
   il rimontaggio del filesystem, con le nuove opzioni indicate da \param{data}
   e dagli altri flag di \param{mountflags};
-\item se è presente il flag \const{MS\_BIND} nel qual caso verrà eseguito un
-  \textit{bind-mount} (argometo che tratteremo più avanti);
+\item se è presente il flag \const{MS\_BIND}, nel qual caso verrà eseguito un
+  \textit{bind mount} (argomento che tratteremo più avanti);
 \item se è presente uno fra \const{MS\_SHARED}, \const{MS\_PRIVATE},
-  \const{MS\_SLAVE}, \const{MS\_UNBINDABLE} nel qual caso viene cambiata la
+  \const{MS\_SLAVE}, \const{MS\_UNBINDABLE}, nel qual caso verrà cambiata la
   modalità di propagazione del montaggio (detti valori sono mutualmente
   esclusivi).
-\item se è presente \const{MS\_MOVE}, nel qual caso viene effettuato uno
-  spostamento del \textit{mount-point};
+\item se è presente \const{MS\_MOVE}, nel qual caso verrà effettuato uno
+  spostamento del \textit{mount point};
 \item se nessuno dei precedenti è presente si tratta di una ordinaria
   operazione di montaggio di un filesystem.
 \end{enumerate*}
@@ -779,18 +779,20 @@ Il fatto che questi valori vengano controllati in quest'ordine significa che
 l'effetto di alcuni di questi flag possono cambiare se usati in combinazione
 con gli altri che vengono prima nella sequenza (è quanto avviene ad esempio
 per \const{MS\_BIND} usato con \const{MS\_REMOUNT}). Tratteremo questi
-\textit{mount flags} speciali per primi, tornando sugli altri più avanti.
+\textit{mount flags} speciali per primi, nell'ordine appena illustrato,
+tornando sugli altri più avanti.
 
 Usando il flag \constd{MS\_REMOUNT} si richiede a \func{mount} di rimontare un
 filesystem già montato cambiandone le opzioni di montaggio in maniera atomica
-(non è cioè necessario smontare e rimontare il filsystem per effettuare il
-cambiamento). In questo modo si possono modificare le opzioni del filesystem
-anche se questo è in uso. Gli argomenti \param{source} e \param{target} devono
-essere gli stessi usati per il montaggio originale, mentre sia \param{data}
-che \param{mountflags} conterranno le nuove opzioni, \param{filesystemtype}
-viene ignorato.  Perché l'operazione abbia successo occorre comunque che il
-cambiamento sia possibile (ad esempio non sarà possibile rimontare in sola
-lettura un filesystem su cui sono aperti file per la lettura/scrittura).
+(non è cioè necessario smontare e rimontare il filesystem per effettuare il
+cambiamento). Questa operazione consente di modificare le opzioni del
+filesystem anche se questo è in uso. Gli argomenti \param{source} e
+\param{target} devono essere gli stessi usati per il montaggio originale,
+mentre sia \param{data} che \param{mountflags} conterranno le nuove opzioni,
+\param{filesystemtype} viene ignorato.  Perché l'operazione abbia successo
+occorre comunque che il cambiamento sia possibile (ad esempio non sarà
+possibile rimontare in sola lettura un filesystem su cui sono aperti file per
+la lettura/scrittura).
 
 Qualunque opzione specifica del filesystem indicata con \param{data} può
 essere modificata (ma si dovranno rielencare tutte quelle volute), mentre con
@@ -799,10 +801,10 @@ essere modificata (ma si dovranno rielencare tutte quelle volute), mentre con
 \const{MS\_NODEV}, \const{MS\_NODIRATIME}, \const{MS\_NOEXEC},
 \const{MS\_NOSUID}, \const{MS\_RELATIME}, \const{MS\_RDONLY},
 \const{MS\_STRICTATIME} e \const{MS\_SYNCHRONOUS}. Inoltre dal kernel 3.17 il
-comportamento relativo alle opzioni che operano sul tempo di ultimo accesso
-(vedi sez.~\ref{sec:file_file_times}) è cambiato e se non si è indicato
-nessuno dei vari \texttt{MS\_*ATIME} vengono mantenute le impostazioni
-esistenti anziché forzare l'uso di \const{MS\_RELATIME}.
+comportamento relativo alle opzioni che operano sui tempi di ultimo accesso
+dei file (vedi sez.~\ref{sec:file_file_times}) è cambiato e se non si è
+indicato nessuno dei vari \texttt{MS\_*ATIME} vengono mantenute le
+impostazioni esistenti anziché forzare l'uso di \const{MS\_RELATIME}.
 
 \itindbeg{bind~mount}
 
@@ -815,13 +817,13 @@ directory che si vuole montare e non un file di dispositivo, e \param{target}
 che indicherà la directory su cui verrà effettuato il \textit{bind mount}. Gli
 argomenti \param{filesystemtype} e \param{data} vengono ignorati.
 
-In sostanza quello che avviene è che in corrispondenza del \textit{pathname}
-indicato da \param{target} viene montato l'\textit{inode} di \param{source},
-così che la porzione di albero dei file presente sotto \param{source} diventi
-visibile allo stesso modo sotto \param{target}. Trattandosi esattamente dei
-dati dello stesso filesystem, ogni modifica fatta in uno qualunque dei due
-rami di albero sarà visibile nell'altro, visto che entrambi faranno
-riferimento agli stessi \textit{inode}.
+Quello che avviene con questa operazione è che in corrispondenza del
+\textit{pathname} indicato da \param{target} viene montato l'\textit{inode} di
+\param{source}, così che la porzione di albero dei file presente sotto
+\param{source} diventi visibile allo stesso modo sotto
+\param{target}. Trattandosi esattamente dei dati dello stesso filesystem, ogni
+modifica fatta in uno qualunque dei due rami di albero sarà visibile
+nell'altro, visto che entrambi faranno riferimento agli stessi \textit{inode}.
 
 Dal punto di vista del VFS l'operazione è analoga al montaggio di un
 filesystem proprio nel fatto che anche in questo caso si inserisce in
@@ -837,34 +839,34 @@ di albero che sta sotto \param{source} qualora in una sottodirectory di
 quest'ultima si fosse effettuato un altro montaggio. In tal caso infatti nella
 porzione di albero sotto \param{source} si troverebbe il contenuto del nuovo
 filesystem (o di un altro \textit{bind mount}) mentre sotto \param{target} ci
-sarebbe il contenuto presente nel filesystem originale.\footnote{questo evita
-  anche il problema dei \textit{loop} di fig.~\ref{fig:file_link_loop}, dato
-  che se anche si montasse su \param{target} una directory in cui essa è
-  contenuta, il cerchio non potrebbe chiudersi perché ritornati a
-  \param{target} dentro il \textit{bind mount} vi si troverebbe solo il
-  contenuto originale e non si potrebbe tornare indietro.}
+sarebbe il contenuto presente nel filesystem originale.
 
 L'unico altro \textit{mount flag} usabile direttamente con \const{MS\_BIND} è
 \const{MS\_REC} che consente di eseguire una operazione di \textit{bind mount}
-ricorsiva, in cui nel nuovo \textit{mount point} vengono montati
-ricorsivamente anche tutti gli eventuali \textit{bind mount} presenti al di
-sotto della directory di origine.
+ricorsiva, in cui sotto \param{target} vengono montati ricorsivamente anche
+tutti gli eventuali ulteriori \textit{bind mount} già presenti sotto
+\param{source}.
 
-E' però possibile, a partire dal kernel 2.6.26 usare questo flag insieme a
+E' però possibile, a partire dal kernel 2.6.26, usare questo flag insieme a
 \const{MS\_REMOUNT}, nel qual caso consente di effettuare una modifica delle
 opzioni di montaggio del \textit{bind mount} ed in particolare effettuare il
 cosiddetto \textit{read-only bind mount} in cui viene onorata anche la
 presenza aggiuntiva del flag \const{MS\_RDONLY}. In questo modo si ottiene che
 l'accesso ai file sotto \param{target} sia effettuabile esclusivamente in sola
-lettura, senza dover cambiare le opzione del \textit{mount-point} originale.
+lettura, mantenendo il normale accesso in lettura/scrittura sotto
+\param{source}.
 
 Il supporto per il \textit{bind mount} consente di superare i limiti presenti
 per gli \textit{hard link} (di cui parleremo in
 sez.~\ref{sec:link_symlink_rename}) con la possibilità di fare riferimento
 alla porzione dell'albero dei file di un filesystem presente a partire da una
-certa directory, utilizzando una qualunque altra directory, anche se questa
-sta su un filesystem diverso. Si può così fornire una alternativa all'uso dei
-collegamenti simbolici (di cui parleremo in
+certa directory utilizzando una qualunque altra directory, anche se questa sta
+su un filesystem diverso.\footnote{e non c'è neanche il problema di non esser
+  più in grado di cancellare un \textit{hard link} ad una directory sullo
+  stesso filesystem (vedi sez.~\ref{sec:link_symlink_rename}), per cui su
+  Linux questi non sono possibili, dato che in questo caso per la rimozione
+  del collegamento basta smontare \param{target}.} Si può così fornire una
+alternativa all'uso dei collegamenti simbolici (di cui parleremo in
 sez.~\ref{sec:link_symlink_rename}) che funziona correttamente anche
 all'intero di un \textit{chroot} (argomento su cui torneremo in
 sez.~\ref{sec:file_chroot}).
@@ -875,84 +877,140 @@ sez.~\ref{sec:file_chroot}).
 I quattro flag \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
 \const{MS\_UNBINDABLE} sono stati introdotti a partire dal kernel 2.6.15 per
 realizzare l'infrastruttura dei cosiddetti \textit{shared subtree}, che
-estendono le funzionalità dei \textit{bind mount} per rendere possibile
-propagare automaticamente o meno le eventuali operazioni di montaggio eseguite
-al di sotto di un \textit{bind mount} a tutti gli altri \textit{mount-point} 
-
-
-consentendo di impostare le
-politiche di propagazione di ulteriori eventuali operazione di montaggio
-effettuate al di sotto di un \textit{bind-mount}. 
-
-L'uso di uno di questi \textit{mount flag}, che si ricordi sono esclusivi fra
-loro, è compatibile solo con In tutti gli altri casi \func{mount} fallirà con
-un errore di \errval{EINVAL}. 
+estendono le funzionalità dei \textit{bind mount}.  La funzionalità nasce
+dalle esigenze di poter utilizzare a pieno le funzionalità di isolamento
+fornite dal kernel per i processi (i \textit{namespace}, che tratteremo in
+sez.~\ref{sec:process_namespaces}) in particolare per quanto riguarda la
+possibilità di far avere ad un processo una visione ristretta dei filesystem
+montati (il \textit{mount namespace}), ma l'applicazione è comunque rilevante
+anche con un classico \textit{chroot} (vedi sez.~\ref{sec:file_chroot}).
+
+\itindbeg{submount}
+
+Abbiamo visto come nella modalità ordinaria in cui si esegue un
+\textit{bind mount} sotto \param{target} compaia lo stesso ramo di albero dei
+file presente sotto \param{source}, ma limitato a quanto presente nel
+filesystem di \param{source}; i risultati di un eventuale
+``\textit{submount}'' effettuato all'interno di \param{source} non saranno
+visibili. Ed anche se quelli presenti al momento dell'uso di \const{MS\_BIND}
+possono essere riottenuti usando \const{MS\_REC}, ogni eventuale
+``\textit{submount}'' successivo (che avvenga sotto \param{source} o sotto
+\param{target}) resterà ``\textsl{privato}'' al ramo di albero su cui è
+avvenuto.
+
+\itindend{submount}
+\itindbeg{mount peer group}
+
+Ci sono casi però in cui può risultare utile che eventuali
+``\textit{submount}'' siano visibili sui rami di albero presenti al di sotto
+di tutte le directory coinvolte in un \textit{bind mount}, anche se effettuati
+in un secondo tempo. Per poter ottenere questa funzionalità i
+\textit{bind mount} sono stati estesi introducendo i \textit{mount peer
+  group}, che consentono di raggrupparli in modo da poter inviare a ciascuno
+di essi tutti gli eventi relativi a montaggi o smontaggi effettuati al loro
+interno ed avere sempre una propagazione degli stessi che li renda coerenti.
+
+Quando si effettua un montaggio ordinario, o si esegue un \textit{bind mount},
+di default non viene utilizzato nessun \textit{mount peer group} ed il
+\textit{mount point} viene classificato come ``\textsl{privato}'', nel senso
+che abbiamo appena visto.  Si può però marcare un \textit{mount point} come
+``\textsl{condiviso}'', ed in questo modo esso verrà associato ad un
+\textit{mount peer group} insieme a tutti gli altri ulteriori \textit{mount
+  point} per i quali sia stato eseguito un \textit{bind mount}. Questo fa sì
+che tutte le volte che si effettua un montaggio o uno smontaggio all'interno
+di uno qualunque dei \textit{mount point} del gruppo, questo venga propagato
+anche su tutti gli altri e sotto tutti sia visibile sempre lo stesso ramo di
+albero dei file.
+
+A completare l'infrastruttura degli \textit{shared subtree} sono state
+previste due ulteriori funzionalità: la prima è quella di marcare un
+\textit{mount point} come ``\textit{slave}'', in tal caso le operazioni di
+montaggio e smontaggio effettuate al suo interno non verranno più propagate
+agli altri membri del \textit{mount peer group} di cui fa parte, ma continuerà
+a ricevere quelle eseguite negli altri membri.
+
+La seconda funzionalità è quella di marcare un \textit{mount point} come
+``\textit{unbindable}''; questo anzitutto impedirà che possa essere usato come
+sorgente di un \textit{bind mount} ed inoltre lo renderà privato, con la
+conseguenza che quando è presente all'interno di altri \textit{bind mount},
+all'interno di questi si vedrà solo il contenuto originale e non quello
+risultante da eventuali ulteriori montaggi effettuati al suo interno.
+
+\itindend{mount peer group}
+
+I \textit{mount flag} che controllano le operazioni relative agli
+\textit{shared subtree} sono descritti nella lista seguente. Si ricordi che
+sono mutuamente esclusivi, e compatibili solo con l'uso degli ulteriori flag
+\const{MS\_REC} (che applica ricorsivamente l'operazione a tutti gli eventuali
+\textit{mount point} sottostanti) e \const{MS\_SILENT}; in tutti gli altri
+casi \func{mount} fallirà con un errore di \errval{EINVAL}. L'unico altro
+argomento che deve essere specificato quando li si usano è \param{target};
+\param{source}, \param{data} e \param{filesystem} sono ignorati.
 
 \begin{basedescript}{\desclabelwidth{1.9cm}\desclabelstyle{\nextlinelabel}}
 
-\item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come privato. In
-  questo caso \param{target} dovrà fare riferimento al \textit{mount point}
-  che si intende marcare, e tutti gli altri argomenti verranno ignorati.
-
-  Di default, finché non lo si marca altrimenti con una delle altre opzioni
-  dell'interfaccia come \textit{shared subtree}, ogni \textit{mount point} è
-  privato. Ogni \textit{bind mount} ottenuto da un \textit{mount point} di
-  tipo \textit{private} si comporta come descritto nella trattazione di
-  \const{MS\_BIND}. Si usa questo flag principalmente per revocare gli effetti
-  delle altre opzioni e riportare il comportamento a quello ordinario.
+\item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come \textit{private
+    mount}.  Di default, finché non lo si marca altrimenti con una delle altre
+  opzioni dell'interfaccia, ogni \textit{mount point} è privato. Ogni
+  \textit{bind mount} ottenuto da un \textit{mount point} privato si comporta
+  come descritto nella trattazione di \const{MS\_BIND}. Si usa questo flag
+  principalmente per revocare gli effetti delle altre opzioni e riportare il
+  comportamento a quello ordinario.
 
 \item[\constd{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared
-    mount}. In questo caso \param{target} dovrà fare riferimento al
-  \textit{mount point} che si intende marcare, e tutti gli altri argomenti
-  verranno ignorati.
-
-  Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
-  effettuati da un \textit{mount point} marcato da essa siano di tipo
-  \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
-  ogni ulteriore operazione di montaggio o smontaggio che avviene su una
-  directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
-  smontaggio effettuate al di sotto di un qualunque \textit{mount point} così
-  marcato verranno ``\textsl{propagate}'' a tutti i \textit{mount point} della
-  stessa condivisione, e la sezione di albero di file vista al di sotto di
-  ciascuno di essi sarà sempre identica.
+    mount}.  Lo scopo dell'opzione è ottenere che tutti i successivi
+  \textit{bind mount} ottenuti da un \textit{mount point} così marcato siano
+  di tipo \textit{shared} e vengano inseriti nello stesso \textit{mount peer
+    group} in modo da ``\textsl{condividere}'' ogni ulteriore operazione di
+  montaggio o smontaggio. Con questa opzione le operazioni di montaggio e
+  smontaggio effettuate al di sotto di uno \textit{shared mount} vengono
+  automaticamente ``\textsl{propagate}'' a tutti gli altri membri del
+  \textit{mount peer group} di cui fa parte, in modo che la sezione di albero
+  dei file visibile al di sotto di ciascuno di essi sia sempre la stessa.
 
 \item[\constd{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave
-    mount}.  In questo caso \param{target} dovrà fare riferimento al
-  \textit{mount point} che si intende marcare, e tutti gli altri argomenti
-  verranno ignorati.
-
-  Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
-  effettuati da un \textit{mount point} marcato da essa siano di tipo
-  \textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di
-  montaggio o smontaggio che avviene su una directory al di sotto del
-  \textit{mount point} originale. Le operazioni di montaggio e smontaggio in
-  questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
-  originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
-  essi potranno eseguire al loro interno ulteriori montaggi che non saranno
-  propagati né negli altri né nel \textit{mount point} originale.
+    mount}. Se il \textit{mount point} è parte di un \textit{mount peer group}
+  esso diventerà di tipo \textit{slave}: le operazioni di montaggio e
+  smontaggio al suo interno non verranno più propagate agli altri membri del
+  gruppo, ma continuerà a ricevere quelle eseguite negli altri membri. Se non
+  esistono altri membri nel gruppo il \textit{mount point} diventerà privato,
+  negli altri casi non subirà nessun cambiamento.
 
 \item[\constd{MS\_UNBINDABLE}] Marca un \textit{mount point} come
-  \textit{unbindable mount}.  In questo caso \param{target} dovrà fare
-  riferimento al \textit{mount point} che si intende marcare, e tutti gli
-  altri argomenti verranno ignorati.
-
-  Un \textit{mount point} marcato in questo modo disabilita la capacità di
-  eseguire dei \textit{bind mount} del suo contenuto. Si comporta cioè come
-  allo stesso modo di un \textit{mount point} ordinario di tipo
-  \textit{private} con in più la restrizione che nessuna sua sottodirectory
-  (anche se relativa ad un ulteriore montaggio) possa essere utilizzata per un
-  come sorgente di un \textit{bind mount}.
+  \textit{unbindable mount}.  Un \textit{mount point} marcato in questo modo
+  non può essere usato per un \textit{bind mount} del suo contenuto. Si
+  comporta cioè come allo stesso modo di un \textit{mount point} ordinario di
+  tipo \textit{private} con in più la restrizione che nessuna sua
+  sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere
+  utilizzata come sorgente di un \textit{bind mount}.
   
 \end{basedescript}
 \itindend{shared~subtree}
 
-
-\begin{basedescript}{\desclabelwidth{1.9cm}\desclabelstyle{\nextlinelabel}}
+L'ultimo \textit{mount flag} che controlla una modalità operativa di
+\func{mount} è \constd{MS\_MOVE}, che consente di effettuare lo spostamento
+del \textit{mount point} di un filesystem. La directory del \textit{mount
+  point} originale deve essere indicata nell'argomento \param{source}, e la
+sua nuova posizione nell'argomento \param{target}. Tutti gli altri argomenti
+della funzione vengono ignorati.
+
+Lo spostamento avviene atomicamente, ed il ramo di albero presente sotto
+\param{source} sarà immediatamente visibile sotto \param{target}. Non esiste
+cioè nessun momento in cui il filesystem non risulti montato in una o
+nell'altra directory e pertanto è garantito che la risoluzione di
+\textit{pathname} relativi all'interno del filesystem non possa fallire.
+
+Elenchiamo infine i restanti \textit{mount flag}, il cui utilizzo non attiene
+alle operazioni di \func{mount}, ma soltanto l'impostazione di opzioni
+generiche relative al funzionamento di un filesystem e che vengono per lo più
+utilizzati solo in fase di montaggio:
+
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
 \item[\constd{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
   directory venga immediatamente registrata su disco in maniera sincrona
   (introdotta a partire dai kernel della serie 2.6). L'opzione si applica a
   tutte le directory del filesystem, ma su alcuni filesystem è possibile
-  impostarla a livello di singole directory o per i sottorami di una directory
+  impostarla a livello di singole directory o per i sotto-rami di una directory
   con il comando \cmd{chattr}.\footnote{questo avviene tramite delle opportune
     \texttt{ioctl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).}
 
@@ -962,35 +1020,38 @@ un errore di \errval{EINVAL}.
   operazioni sulle directory non saranno più bufferizzate e si bloccheranno
   fino all'arrivo dei dati sul disco prima che un programma possa proseguire.
 
+\item[\constd{MS\_LAZYTIME}] Modifica la modalità di registrazione di tempi
+  dei file (vedi sez.~\ref{sec:file_file_times}) per ridurre al massimo gli
+  accessi a disco (particolarmente utile per i portatili). Attivandolo i tempi
+  dei file vengono mantenuti in memoria e vengono salvati su disco solo in
+  quattro casi: quando c'è da eseguire un aggiornamento dei dati
+  dell'\textit{inode} per altri motivi, se viene usata una delle funzioni di
+  sincronizzazione dei dati su disco (vedi sez.~\ref{sec:file_sync}), se
+  l'\textit{inode} viene rimosso dalla memoria, o se è passato un giorno
+  dall'ultima registrazione. Introdotto a partire dal kernel 4.0.
+
+  In questo modo si possono ridurre significativamente le scritture su disco
+  mantenendo tutte le informazioni riguardo ai tempi dei file, riducendo anche
+  l'impatto dell'uso di \const{MS\_STRICTATIME}. Il costo da pagare è il
+  rischio, in caso di crash del sistema, di avere dati vecchi fino a 24 ore
+  per quel che riguarda i tempi dei file.
+  
 \item[\constd{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
   (vedi sez.~\ref{sec:file_mand_locking}) sui file del filesystem. Per poterlo
   utilizzare effettivamente però esso dovrà essere comunque attivato
   esplicitamente per i singoli file impostando i permessi come illustrato in
   sez.~\ref{sec:file_mand_locking}.
 
-\item[\constd{MS\_MOVE}] Effettua uno del spostamento del \textit{mount point}
-  di un filesystem. La directory del \textit{mount point} originale deve
-  essere indicata nell'argomento \param{source}, e la sua nuova posizione
-  nell'argomento \param{target}. Tutti gli altri argomenti della funzione
-  vengono ignorati.
-
-  Lo spostamento avviene atomicamente, ed il ramo di albero presente
-  sotto \param{source} sarà immediatamente visibile sotto \param{target}. Non
-  esiste cioè nessun momento in cui il filesystem non risulti montato in una o
-  nell'altra directory e pertanto è garantito che la risoluzione di
-  \textit{pathname} relativi all'interno del filesystem non possa fallire.
-
 \item[\constd{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
   dell'\textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
-  qualunque tipo di file. Dato che l'aggiornamento dell'\textit{access time}
-  è una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
+  qualunque tipo di file. Dato che l'aggiornamento dell'\textit{access time} è
+  una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
   elevato visto che una qualunque lettura comporta comunque una scrittura su
-  disco,\footnote{e questo ad esempio ha conseguenze molto pesanti nell'uso
-    della batteria sui portatili.} questa opzione consente di disabilitarla
-  completamente. La soluzione può risultare troppo drastica dato che
-  l'informazione viene comunque utilizzata da alcuni programmi, per cui nello
-  sviluppo del kernel sono state introdotte altre opzioni che forniscono
-  soluzioni più appropriate e meno radicali.
+  disco, questa opzione consente di disabilitarla completamente. La soluzione
+  può risultare troppo drastica dato che l'informazione viene comunque
+  utilizzata da alcuni programmi, per cui nello sviluppo del kernel sono state
+  introdotte altre opzioni che forniscono soluzioni più appropriate e meno
+  radicali.
 
 \item[\constd{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
   di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
@@ -1051,21 +1112,19 @@ un errore di \errval{EINVAL}.
   questo non venga modificato (ad esempio per ispezionare un filesystem
   corrotto). All'avvio di default il kernel monta la radice in questa
   modalità. Si tenga presente che se non viene indicato il filesystem verrà
-  montato, o rimontanto nel caso lo si usi con \const{MS\_REMOUNT}, in
+  montato, o rimontato nel caso lo si usi con \const{MS\_REMOUNT}, in
   lettura/scrittura; questo significa in sostanza che non esiste una opzione
   separata per indicare il montaggio in lettura/scrittura.
 
 \item[\constd{MS\_REC}] Applica ricorsivamente a tutti i \textit{mount point}
   presenti al di sotto del \textit{mount point} indicato gli effetti della
-  opzione degli \textit{shared subtree} associata. Anche questo caso
-  l'argomento \param{target} deve fare riferimento ad un \textit{mount point}
-  e tutti gli altri argomenti sono ignorati, ed il flag deve essere indicato o
-  con \const{MS\_BIND} o assieme ad una fra \const{MS\_PRIVATE},
-  \const{MS\_SHARED}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}. Presente dal
-  kernel 2.4.11.
-
-  % TODO trattare l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
-  % vedi http://lwn.net/Articles/621046/
+  opzione degli \textit{shared subtree} associata. In questo caso l'argomento
+  \param{target} deve fare riferimento ad un \textit{mount point} e tutti gli
+  altri argomenti sono ignorati, ed il flag deve essere indicato con uno fra
+  \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+  \const{MS\_UNBINDABLE}. Può anche essere usato con \const{MS\_BIND} per
+  richiedere il montaggio ricorsivo anche degli eventuali ulteriori
+  \textit{bind mount} presenti sotto \param{target}.
 
 \item[\constd{MS\_RELATIME}] Indica di effettuare l'aggiornamento
   dell'\textit{access time} sul filesystem soltanto quando questo risulti
@@ -1114,6 +1173,9 @@ un errore di \errval{EINVAL}.
 
 \end{basedescript}
 
+% NOTE: per l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
+% vedi http://lwn.net/Articles/621046/
+
 % NOTE per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE} e
 % \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, in particolare
 %  * http://lwn.net/Articles/159077/ e
@@ -1247,7 +1309,7 @@ Infine il flag \constd{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se
 questo è un collegamento simbolico (vedi
 sez.~\ref{sec:link_symlink_rename}). Questa è una misura di sicurezza
 introdotta per evitare, per quei filesystem per il quale è prevista una
-gestione diretta da parte degli utenti, come quelli basati su
+gestione diretta da parte degli utenti, come quelli basati su \itindex{FUSE}
 FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
   interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
   di implementarne le funzioni in \textit{user space}, così da rendere
@@ -1389,9 +1451,9 @@ fanno comunque riferimento allo stesso \textit{inode} e quindi tutti
 otterranno lo stesso file.
 
 Quando si vuole aggiungere ad una directory una voce che faccia riferimento ad
-un file già esistente nella modalità appena descritta, per ottenere quello che
-viene denominato ``\textsl{collegamento diretto}'' (o \textit{hard link}), si
-deve usare la funzione di sistema \funcd{link}, il cui prototipo è:
+un file già esistente come appena descritto, per ottenere quello che viene
+denominato ``\textsl{collegamento diretto}'' (o \textit{hard link}), si deve
+usare la funzione di sistema \funcd{link}, il cui prototipo è:
 
 \begin{funcproto}{
 \fhead{unistd.h}
@@ -1407,23 +1469,30 @@ deve usare la funzione di sistema \funcd{link}, il cui prototipo è:
     (il numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
     sez.~\ref{sec:sys_limits}).
   \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
-    \param{newpath} non supporta i collegamenti diretti o è una directory.
+    \param{newpath} non supporta i collegamenti diretti, è una directory o per
+    \param{oldpath} non si rispettano i criteri per i \textit{protected
+      hardlink}.\footnotemark 
   \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
     riferimento ad un filesystem montato sullo stesso 
     \textit{mount point}.
-  \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
-  \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
-  \errval{ENOSPC}, \errval{ENOTDIR}, \errval{EROFS} nel loro significato
-  generico.}
+  \end{errlist} ed inoltre \errval{EACCES}, \errval{EDQUOT}, \errval{EFAULT},
+  \errval{EIO}, \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+  \errval{ENOMEM}, \errval{ENOSPC}, \errval{ENOTDIR}, \errval{EROFS} nel loro
+  significato generico.}
 \end{funcproto}
 
+\footnotetext{i \textit{protected hardlink} sono una funzionalità di
+  protezione introdotta con il kernel 3.16 (si veda
+  sez.~\ref{sec:procadv_security_misc} per i dettagli) che limita la capacità
+  di creare un \textit{hard link} ad un file qualunque.}
+
 La funzione crea in \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 la voce
 specificata da \param{newpath} nella directory corrispondente e l'unica
 proprietà del file che verrà modificata sarà il numero di riferimenti al file
 (il campo \var{i\_nlink} della struttura \kstruct{inode}, vedi
-fig.~\ref{fig:kstruct_inode}) che verrà aumentato di di uno. In questo modo lo
+fig.~\ref{fig:kstruct_inode}) che verrà aumentato di uno. In questo modo lo
 stesso file potrà essere acceduto sia con \param{newpath} che
 con \param{oldpath}.
 
@@ -1437,25 +1506,22 @@ riferimento ad essi all'interno dello stesso \textit{mount point}.\footnote{si
   tenga presente infatti, come detto in sez.~\ref{sec:filesystem_mounting},
   che a partire dal kernel 2.4 uno stesso filesystem può essere montato più
   volte su directory diverse.}
-
 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 \textit{loop} nel filesystem (vedi fig.~\ref{fig:file_link_loop})
-che molti programmi non sono in grado di gestire e la cui rimozione
-diventerebbe piuttosto complicata.\footnote{in genere per questo tipo di
-  errori occorre eseguire il programma \cmd{fsck} per riparare il filesystem,
-  in quanto in caso di \textit{loop} la directory creata non sarebbe vuota e
-  non si potrebbe più rimuoverla.}
-
-Data la pericolosità di questa operazione e la disponibilità dei collegamenti
-simbolici (che vedremo a breve) e dei \textit{bind mount}
-(già visti in sez.~\ref{sec:filesystem_mounting}) che possono fornire la
-stessa funzionalità senza questi problemi, nel caso di Linux questa capacità è
-stata completamente disabilitata, e al tentativo di creare un collegamento
-diretto ad una directory la funzione \func{link} restituisce sempre l'errore
-\errcode{EPERM}.
+la cui rimozione diventerebbe piuttosto complicata.\footnote{occorrerebbe
+  infatti eseguire il programma \cmd{fsck} per riparare il filesystem, perché
+  in caso di \textit{loop} la directory non potrebbe essere più svuotata,
+  contenendo comunque se stessa, e quindi non potrebbe essere rimossa.}
+
+Data la pericolosità di questa operazione, e visto che i collegamenti
+simbolici (che tratteremo a breve) ed i \textit{bind mount} (già visti in
+sez.~\ref{sec:filesystem_mounting}) possono fornire la stessa funzionalità
+senza questi problemi, nel caso di Linux questa capacità è stata completamente
+disabilitata, e al tentativo di creare un collegamento diretto ad una
+directory la funzione \func{link} restituisce sempre l'errore \errcode{EPERM}.
 
 Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
 \textit{hard link} ad un collegamento simbolico. In questo caso lo standard
@@ -1532,6 +1598,8 @@ sistema che permette di creare un nuovo collegamento simbolico è
 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
+  \item[\errcode{EACCES}]  o non si hanno i permessi sulla directory in cui
+    creare il \textit{link}.
   \item[\errcode{EEXIST}] esiste già un file \param{newpath}.
   \item[\errcode{ENOENT}] una componente di \param{newpath} non esiste o
     \param{oldpath} è una stringa vuota.
@@ -1539,11 +1607,12 @@ sistema che permette di creare un nuovo collegamento simbolico è
     supporta i collegamenti simbolici.
   \item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
     lettura.
-  \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
+  \end{errlist} ed inoltre \errval{EDQUOT}, \errval{EFAULT}, \errval{EIO},
   \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOMEM}, \errval{ENOSPC} e
   \errval{ENOTDIR} nel loro significato generico.}
 \end{funcproto}
 
+
 La funzione crea un nuovo collegamento simbolico \param{newpath} che fa
 riferimento ad \param{oldpath}.  Si tenga presente che la funzione non
 effettua nessun controllo sull'esistenza di un file di nome \param{oldpath},
@@ -1551,7 +1620,30 @@ ma si limita ad inserire il \textit{pathname} nel collegamento
 simbolico. Pertanto un collegamento simbolico può anche riferirsi ad un file
 che non esiste ed in questo caso si ha quello che viene chiamato un
 \itindex{dangling~link} \textit{dangling link}, letteralmente un
-\index{collegamento!ciondolante} ``\textsl{collegamento ciondolante}''.
+\index{collegamento!ciondolante} ``\textsl{collegamento ciondolante}''. Ad
+esempio possiamo usare il comando \cmd{ln} per creare un collegamento
+simbolico nella nostra directory con:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
+\end{Console}
+%$
+e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ls symlink}
+symlink
+\end{Console}
+%$
+ma questo può generare confusione, perché accedendo in lettura a
+\file{symlink}, ad esempio con \cmd{cat}, otterremmo:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{cat symlink}
+cat: symlink: No such file or directory
+\end{Console}
+%$
+con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato in
+precedenza l'esistenza di \file{symlink}. Se invece andassimo a scrivere su
+\file{symlink}, l'effetto sarebbe quello di ottenere la creazione di
+\file{/tmp/tmp\_file} (che a quel punto verrebbe creato) senza errori.
 
 Come accennato i collegamenti simbolici sono risolti automaticamente dal
 kernel all'invocazione delle varie \textit{system call}. In
@@ -1604,6 +1696,13 @@ funzione che restituisce il file descriptor (normalmente la \func{open}, vedi
 sez.~\ref{sec:file_open_close}) e tutte le operazioni seguenti fanno
 riferimento solo a quest'ultimo.
 
+Si tenga anche presente che a partire dal kernel 3.16, se si abilita la
+funzionalità dei \textit{protected symlinks} (attiva di default in tutte le
+distribuzioni più recenti) la risoluzione dei nomi attraverso un collegamento
+simbolico può fallire per una serie di restrizione di sicurezza aggiuntive
+imposte dal meccanismo (si consulti sez.~\ref{sec:procadv_security_misc} per i
+dettagli del meccanismo).
+
 Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
 \func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
 accedere alle informazioni del collegamento invece che a quelle del file a cui
@@ -1612,30 +1711,32 @@ simbolico si usa la funzione di sistema \funcd{readlink}, il cui prototipo è:
 
 \begin{funcproto}{
 \fhead{unistd.h}
-\fdecl{int readlink(const char *path, char *buff, size\_t size)}
+\fdecl{int readlink(const char *pathname, char *buff, size\_t size)}
 \fdesc{Legge il contenuto di un collegamento simbolico.} 
 }
 {La funzione ritorna il numero di caratteri letti dentro \param{buff} in caso
   di successo e $-1$ per un errore,  nel qual caso \var{errno} assumerà uno
   dei valori:
   \begin{errlist}
-  \item[\errcode{EINVAL}] \param{path} non è un collegamento simbolico
+  \item[\errcode{EACCES}] non si hanno i permessi di attraversamento di una
+    delle directory del pathname
+  \item[\errcode{EINVAL}] \param{pathname} non è un collegamento simbolico
     o \param{size} non è positiva.
-  \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
-  \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM} e
-  \errval{ENOTDIR} nel loro significato generico.}
+  \end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
+  \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}
+  nel loro significato generico.}
 \end{funcproto}
 
 La funzione legge il \textit{pathname} a cui fa riferimento il collegamento
-simbolico indicato dall'argomento \param{path} scrivendolo sul
-buffer \param{buff} di dimensione \param{size}. Si tenga presente che la
-funzione non termina la stringa con un carattere nullo e che se questa è
-troppo lunga la tronca alla dimensione specificata da \param{size} per evitare
-di sovrascrivere oltre le dimensioni del buffer.
+simbolico indicato dall'argomento \param{pathname} scrivendolo sul buffer
+\param{buff} di dimensione \param{size}. Si tenga presente che la funzione non
+termina la stringa con un carattere nullo e che se questa è troppo lunga la
+tronca alla dimensione specificata da \param{size} per evitare di scrivere
+dati oltre le dimensioni del buffer.
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=8.5cm]{img/link_loop}
+  \includegraphics[width=8cm]{img/link_loop}
   \caption{Esempio di loop nel filesystem creato con un collegamento
     simbolico.}
   \label{fig:file_link_loop}
@@ -1646,68 +1747,41 @@ alle directory è che questi possono creare dei \textit{loop} nella risoluzione
 dei nomi che non possono essere eliminati facilmente. Invece è sempre
 possibile, ed in genere anche molto utile, creare un collegamento simbolico ad
 una directory, anche se in questo caso si potranno ottenere anche dei
-\textit{loop}. La situazione è illustrata in fig.~\ref{fig:file_link_loop},
-che riporta la struttura della directory \file{/boot}. Come si vede si è
-creato al suo interno un collegamento simbolico che punta di nuovo a
+\textit{loop}.
+
+La situazione è illustrata in fig.~\ref{fig:file_link_loop}, che riporta la
+struttura della directory \file{/boot}. Come si vede si è creato al suo
+interno un collegamento simbolico che punta di nuovo a
 \file{/boot}.\footnote{il \textit{loop} mostrato in
-  fig.~\ref{fig:file_link_loop} è stato 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 \textit{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 vedrebbe 
-  come \file{/}).}
-
-Questo però può causare problemi per tutti quei programmi che effettuano la
-scansione di una directory senza tener conto dei collegamenti simbolici, ad
-esempio se lanciassimo un comando del tipo \code{grep -r linux *}, il loop
-nella directory porterebbe il comando ad esaminare \file{/boot},
-\file{/boot/boot}, \file{/boot/boot/boot} e così via.
+  fig.~\ref{fig:file_link_loop} è stato usato per poter permettere a al
+  \textit{bootloader} \cmd{grub} di vedere i file contenuti nella directory
+  \file{/boot} con lo stesso \textit{pathname} con cui verrebbero visti dal
+  sistema operativo, anche quando si trovano, come accade spesso, su una
+  partizione separata (che \cmd{grub} all'avvio vedrebbe come \file{/}).} Un
+\textit{loop} di di questo tipo però può causare problemi per tutti i
+programmi che effettuano la scansione di una directory, e ad esempio se
+lanciassimo un comando come \code{grep -r linux *}, il \textit{loop} nella
+directory porterebbe ad esaminare \file{/boot}, \file{/boot/boot},
+\file{/boot/boot/boot} e così via.
 
 Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
 un \textit{pathname} possano essere seguiti fino ad un certo numero massimo di
 collegamenti simbolici, il cui valore limite è specificato dalla costante
-\constd{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
-errore ed \var{errno} viene impostata al valore \errcode{ELOOP}, che nella
-quasi totalità dei casi indica appunto che si è creato un collegamento
-simbolico che fa riferimento ad una directory del suo stesso
-\textit{pathname}.
-
-Un altro punto da tenere sempre presente è che, come abbiamo accennato, un
-collegamento simbolico può fare riferimento anche ad un file che non esiste;
-ad esempio possiamo usare il comando \cmd{ln} per creare un collegamento
-simbolico nella nostra directory con:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
-\end{Console}
-%$
-e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{ls symlink}
-symlink
-\end{Console}
-%$
-ma questo può generare confusione, perché accedendo in sola lettura a
-\file{symlink}, ad esempio con \cmd{cat}, otterremmo un errore:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{cat symlink}
-cat: symlink: No such file or directory
-\end{Console}
-%$
-con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato
-l'esistenza di \file{symlink}, se invece scrivessimo su \file{symlink}
-otterremmo la creazione di \file{/tmp/tmp\_file} senza errori.
+\constd{MAXSYMLINKS}. Se il limite viene superato si ha un errore ed
+\var{errno} viene impostata al valore \errcode{ELOOP}, che nella quasi
+totalità dei casi indica appunto che si è creato un collegamento simbolico che
+fa riferimento ad una directory del suo stesso \textit{pathname}.
 
 
 \itindend{symbolic~link}
 \index{collegamento!simbolico|)}
 
 Un'altra funzione relativa alla gestione dei nomi dei file, anche se a prima
-vista parrebbe riguardare un argomento completamente diverso, è quella che per
-la cancellazione di un file. In realtà una \textit{system call} che serva
-proprio a cancellare un file non esiste neanche perché, come accennato in
+vista parrebbe riguardare un argomento completamente diverso, è quella per la
+cancellazione di un file. In realtà una \textit{system call} che serva proprio
+a cancellare un file non esiste neanche perché, come accennato in
 sez.~\ref{sec:file_filesystem}, quando in un sistema unix-like si richiede la
-rimozione di un file quella che si va a cancellare è soltanto la voce che
+rimozione di un file, quello che si va a cancellare è soltanto la voce che
 referenzia il suo \textit{inode} all'interno di una directory.
 
 La funzione di sistema che consente di effettuare questa operazione, il cui
@@ -1723,13 +1797,16 @@ nome come si può notare ha poco a che fare con il concetto di rimozione, è
   nel qual caso \var{errno} assumerà uno dei valori:\footnotemark  
   \begin{errlist}
   \item[\errcode{EACCES}] non si ha il permesso di scrittura sulla directory
-    che contiene \param{pathname} o di attraversamento di una delle directory
-    superiori. 
+    che contiene \param{pathname} o quello di attraversamento per una delle
+    directory superiori.
+  \item[\errcode{EBUSY}] \param{pathname} non può essere rimosso perché è in
+    uso da parte del sistema (in particolare per i cosiddetti \textit{silly
+      renames} di NFS).
   \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una
     directory.
   \item[\errcode{EPERM}] il filesystem non consente l'operazione, o la
     directory che contiene \param{pathname} ha lo \textit{sticky bit} e non si
-    è il proprietario o non si hanno privilegi amministrativi. 
+    è il proprietario del file o non si hanno privilegi amministrativi. 
   \end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
   \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EROFS} nel loro
   significato generico.}
@@ -1746,55 +1823,60 @@ nome come si può notare ha poco a che fare con il concetto di rimozione, è
 
 La funzione elimina il nome specificato dall'argomento \param{pathname} nella
 directory che lo contiene e decrementa il numero di riferimenti nel relativo
-\textit{inode}.\footnote{come per \func{link} queste due operazioni sono
-  effettuate all'interno della \textit{system call} in maniera atomica.} Nel
-caso di socket, \textit{fifo} o file di dispositivo rimuove il nome, ma come
-per i file normali i processi che hanno aperto uno di questi oggetti possono
-continuare ad utilizzarli.  Nel caso di cancellazione di un collegamento
-simbolico, che consiste solo nel rimando ad un altro file, questo viene
-immediatamente eliminato.
+\textit{inode}; come per \func{link} queste due operazioni sono effettuate
+all'interno della \textit{system call} in maniera atomica rispetto ai
+processi.
+
+Si ricordi che, anche se se ne è rimosso il nome, un file viene realmente
+cancellato soltanto quando il numero di collegamenti mantenuto
+nell'\textit{inode} diventa nullo; solo allora l'\textit{inode} viene
+disallocato e lo spazio che il file occupava sul disco viene liberato.
+
+Si tenga presente comunque che a questo si aggiunge sempre un'ulteriore
+condizione e cioè che non ci siano processi che stiano ancora lavorando sul il
+file. Come vedremo in sez.~\ref{sec:file_unix_interface} il kernel una tabella
+di tutti file aperti da ciascun processo, che a sua volta contiene i
+riferimenti agli \textit{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'\textit{inode} in questione, assicurandosi con
+questo che nessun processo stia ancora usando il file.
+
+Nel caso di socket, \textit{fifo} o file di dispositivo la funzione rimuove il
+nome, e come per i file normali i processi che hanno aperto uno di questi
+oggetti possono continuare ad utilizzarli.  Nel caso di cancellazione di un
+\textit{link} simbolico, che consiste solo nel rimando ad un altro file,
+questo viene immediatamente eliminato e non sarà più utilizzabile. 
 
 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/attraversamento sulla directory che la contiene
 (affronteremo in dettaglio l'argomento dei permessi di file e directory in
-sez.~\ref{sec:file_access_control}). Se inoltre lo \textit{sticky bit} (vedi
-sez.~\ref{sec:file_special_perm}) è impostato occorrerà anche essere
-proprietari del file o proprietari della directory o avere i privilegi di
-amministratore.
-
-Si ricordi inoltre che anche se se ne è rimosso il nome da una directory, un
-file non viene eliminato dal disco fintanto che tutti i riferimenti ad esso
-sono stati cancellati: solo quando il numero di collegamenti mantenuto
-nell'\textit{inode} diventa nullo, questo viene disallocato e lo spazio
-occupato su disco viene liberato. Si tenga presente comunque che a questo si
-aggiunge sempre un'ulteriore condizione e cioè che non ci siano processi che
-abbiano il suddetto file aperto.\footnote{come vedremo in
-  sez.~\ref{sec:file_unix_interface} il kernel mantiene anche una tabella dei
-  file aperti nei vari processi, che a sua volta contiene i riferimenti agli
-  \textit{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'\textit{inode} in questione.}
-
-Questa caratteristica del sistema può essere usata per essere sicuri di non
-lasciare file temporanei su disco in caso di crash di un programma. La tecnica
-è quella di aprire un nuovo file e chiamare \func{unlink} su di esso subito
+sez.~\ref{sec:file_access_control}). Se inoltre per la directory è impostato
+lo \textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}), occorrerà
+anche essere proprietari del file o proprietari della directory o avere i
+privilegi di amministratore.
+
+Questa caratteristica del sistema, che consente di usare un file anche se lo
+si è ``cancellato'', può essere usata per essere sicuri di non lasciare file
+temporanei su disco in caso di uscita imprevista di un programma. La tecnica è
+quella di aprire un nuovo file e chiamare \func{unlink} su di esso subito
 dopo, in questo modo il contenuto del file sarà sempre disponibile all'interno
 del processo attraverso il suo file descriptor (vedi sez.~\ref{sec:file_fd}),
-ma non ne resta traccia in nessuna directory, e lo spazio occupato su disco
-viene immediatamente rilasciato alla conclusione del processo, quando tutti i
-file vengono chiusi.
+ma non ne resterà traccia in nessuna directory, inoltre lo spazio occupato su
+disco verrà immediatamente rilasciato alla conclusione del processo, quando
+tutti i file vengono chiusi.
 
 Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
-la funzione \func{unlink} sulle directory, nel qual caso si otterrebbe un
+la funzione \func{unlink} sulle directory, che in tal caso fallisce con un
 errore di \errcode{EISDIR}. Per cancellare una directory si deve usare la
 apposita funzione di sistema \func{rmdir} (che vedremo in
 sez.~\ref{sec:file_dir_creat_rem}), oppure la funzione \func{remove}.
+
 Quest'ultima è la funzione prevista dallo standard ANSI C per effettuare una
-cancellazione generica di un file o di una directory e funziona anche per i
-sistemi operativo che non supportano gli \textit{hard link}. Nei sistemi
-unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
+cancellazione generica di un file o di una directory e viene usata in generale
+anche per i sistemi operativi che non supportano gli \textit{hard link}. Nei
+sistemi unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
 \func{unlink} per i file ed \func{rmdir} per le directory; il suo prototipo è:
 
 \begin{funcproto}{
@@ -1808,13 +1890,15 @@ unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
   \func{unlink} e \func{rmdir}.}
 \end{funcproto}
 
-La funzione utilizza la funzione \func{unlink} per cancellare i file e la
-funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per cancellare
-le directory.\footnote{questo vale usando la \acr{glibc}; nella \acr{libc4} e
-  nella \acr{libc5} la funzione \func{remove} era un semplice alias alla
-  funzione \func{unlink} e quindi non poteva essere usata per le directory.}
-Si tenga presente che per alcune implementazioni del protocollo NFS utilizzare
-questa funzione può comportare la scomparsa di file ancora in uso.
+La funzione utilizza la funzione \func{unlink} per cancellare i file (e si
+applica anche a link simbolici, socket, \textit{fifo} e file di dispositivo) e
+la funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per
+cancellare le directory.\footnote{questo vale usando la \acr{glibc}; nella
+  \acr{libc4} e nella \acr{libc5} la funzione \func{remove} era un semplice
+  alias alla funzione \func{unlink} e quindi non poteva essere usata per le
+  directory.}  Si tenga presente che, per alcune limitazioni del protocollo
+NFS, utilizzare questa funzione su file che usano questo filesystem di rete
+può comportare la scomparsa di file ancora in uso.
 
 Infine per cambiare nome ad un file o a una directory si usa la funzione di
 sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C,
@@ -1829,9 +1913,9 @@ sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C,
 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
-  \item[\errcode{EACCESS}] non c'è permesso di scrivere nelle directory
+  \item[\errcode{EACCESS}] manca il permesso di scrittura sulle directory
     contenenti \param{oldpath} e \param{newpath} o di attraversare 
-    quelle dei loro \textit{pathname} o di scrivere su \param{newpath}
+    il loro \textit{pathname} o di scrivere su \param{newpath}
     se questa è una directory.
   \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
@@ -2010,6 +2094,12 @@ nella directory genitrice, questo significa che \textit{pathname} terminanti
 in ``\file{.}'' e ``\file{..}'' anche se validi in altri contesti, causeranno
 il fallimento della funzione.
 
+Inoltre per eseguire la cancellazione, oltre ad essere vuota, occorre anche
+che la directory non sia utilizzata, questo vuol dire anche che non deve
+essere la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) o la
+directory radice (vedi sez.~\ref{sec:file_chroot}) di nessun processo, od
+essere utilizzata come \textit{mount point}.
+
 Se la directory cancellata risultasse aperta in qualche processo per una
 lettura dei suoi contenuti (vedi sez.~\ref{sec:file_dir_read}), pur
 scomparendo dal filesystem e non essendo più possibile accedervi o crearvi
@@ -2460,7 +2550,7 @@ estensione\footnote{la \acr{glibc}, a partire dalla versione 2.1, effettua
 \func{versionsort}, che ordina i nomi tenendo conto del numero di versione,
 cioè qualcosa per cui \texttt{file10} viene comunque dopo \texttt{file4}.
 
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/my_ls.c}
@@ -2495,11 +2585,11 @@ dati ad esso relativi, per poi provvedere (\texttt{\small 27}) a stampare il
 nome del file e la dimensione riportata in \var{data}.
 
 Dato che la funzione verrà chiamata all'interno di \myfunc{dir\_scan} per ogni
-voce presente questo è sufficiente a stampare la lista completa dei file e
+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}[!htbp]
+\begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/dir_scan.c}
@@ -2537,7 +2627,7 @@ voce valida, cioè un puntatore diverso da \val{NULL}, si esegue
 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 \textit{stream}\footnote{nel nostro caso,
+chiusura (\texttt{\small 31}) dello \textit{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 i
@@ -2553,14 +2643,14 @@ chiusura (\texttt{\small 32}) dello \textit{stream}\footnote{nel nostro caso,
 \index{directory~di~lavoro|(} 
 
 Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
-directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
-  della sua \kstruct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
-  precisamente nel campo \texttt{pwd} della sotto-struttura
-  \kstruct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
-\textsl{directory di lavoro} (in inglese \textit{current working directory}).
-La directory di lavoro è quella da cui si parte quando un \textit{pathname} è
-espresso in forma relativa, dove il ``\textsl{relativa}'' fa riferimento
-appunto a questa directory.
+directory nell'albero dei file,\footnote{questa viene mantenuta all'interno
+  dei dati della sua \kstruct{task\_struct} (vedi
+  fig.~\ref{fig:proc_task_struct}), più precisamente nel campo \texttt{pwd}
+  della sotto-struttura \kstruct{fs\_struct}.} che è chiamata
+\textsl{directory corrente} o \textsl{directory di lavoro} (in inglese
+\textit{current working directory}).  La directory di lavoro è quella da cui
+si parte quando un \textit{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
@@ -3102,8 +3192,6 @@ non si pongono.
 
 
 
-
-
 \section{La manipolazione delle caratteristiche dei file}
 \label{sec:file_infos}
 
@@ -3114,7 +3202,7 @@ in questa sezione come sia possibile leggere tutte queste informazioni usando
 la funzione \func{stat}, che permette l'accesso a tutti i dati memorizzati
 nell'\textit{inode}; esamineremo poi le varie funzioni usate per manipolare
 tutte queste informazioni, eccetto quelle che riguardano la gestione del
-controllo di accesso, trattate in in sez.~\ref{sec:file_access_control}.
+controllo di accesso, trattate in sez.~\ref{sec:file_access_control}.
 
 
 \subsection{La lettura delle caratteristiche dei file}
@@ -4016,8 +4104,8 @@ 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 all'interno di una una directory (se
-si hanno i permessi adeguati per il medesimo) ma non si potrà vederlo con
+lettura si potrà lo stesso aprire un file all'interno di una directory (se si
+hanno i permessi adeguati per il medesimo) ma non si potrà vederlo con
 \cmd{ls} mancando il permesso di leggere il contenuto della directory. Per
 crearlo o rinominarlo o cancellarlo invece occorrerà avere anche il permesso
 di scrittura per la directory.
@@ -4532,8 +4620,8 @@ di controllo è \funcd{umask}, ed il suo prototipo è:
 \fdesc{Imposta la maschera dei permessi.} 
 }
 
-{La funzione ritorna ritorna il precedente valore della maschera, non sono
-  previste condizioni di errore.}
+{La funzione ritorna il precedente valore della maschera, non sono previste
+  condizioni di errore.}
 \end{funcproto}
 
 La funzione imposta la maschera dei permessi dei bit al valore specificato
@@ -4913,7 +5001,7 @@ tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi:
   cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
   directory ordinarie, se valesse in generale infatti si avrebbe un serio
   problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
-  quali è normale avere avere il permesso di scrittura consentito a tutti gli
+  quali è normale avere il permesso di scrittura consentito a tutti gli
   utenti, come i collegamenti simbolici, o alcuni file di dispositivo come
   \texttt{/dev/null}. Se fosse possibile usare su di essi gli \textit{extended
     user attributes} un utente qualunque potrebbe inserirvi dati a
@@ -5456,7 +5544,7 @@ con la funzione \funcd{acl\_dup}, il cui prototipo è:
 
 {La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo in
   caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
-  assumerà assumerà uno dei valori:
+  assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
     per una ACL.
@@ -5690,7 +5778,7 @@ singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
 indicata viene utilizzata come prefisso per le singole voci. 
 
 L'ultimo argomento, \param{options}, consente di controllare la modalità con
-cui viene generata la rappresentazione testuale. Un valore nullo fa si che
+cui viene generata la rappresentazione testuale. Un valore nullo fa sì che
 vengano usati gli identificatori standard \texttt{user}, \texttt{group},
 \texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
 ai loro valori numerici. Altrimenti si può specificare un valore in forma di
@@ -6597,9 +6685,11 @@ librerie) di cui il server potrebbe avere bisogno.
 % LocalWords:  lazy encfs sshfs setfsent getfsent getfsfile getfsspec endfsent
 % LocalWords:  setmntent getmntent addmntent endmntent hasmntopt such offsetof
 % LocalWords:  member scan attack EOVERFLOW BITS blkcnt rdev FDCWD functions
-% LocalWords:  faccessat grpid lacl AppArmor capsetp mygetfacl
+% LocalWords:  faccessat grpid lacl AppArmor capsetp mygetfacl table Tb MSK
+%  LocalWords:  LAZYTIME submount peer protected hardlink symlinks silly
 
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% End: 
+%  LocalWords:  renames