From: Simone Piccardi <piccardi@gnulinux.it>
Date: Thu, 19 Jan 2012 20:23:57 +0000 (+0000)
Subject: Correzioni varie
X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=5c276f48d2b22a017614dddf8afe47f91af6f628;p=gapil.git

Correzioni varie
---

diff --git a/filedir.tex b/filedir.tex
index 757bc13..f11da2c 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -138,7 +138,7 @@ questo punto verrà inserita nella cache.
 
 Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount}
 della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry}
-iniziale nel \itindex{mount~point} \textit{mount point} dello stesso si avrà
+iniziale nel \itindex{mount~point} \textit{mount point} dello stesso, si avrà
 comunque un punto di partenza. Inoltre essendo questa \textit{dentry} relativa
 a quel tipo di filesystem essa farà riferimento ad un \textit{inode} di quel
 filesystem, e come vedremo questo farà sì che venga eseguita una
@@ -458,7 +458,7 @@ opportuno tenere sempre presente che:
   che contiene riferimenti ad \textit{inode} relativi ad altri filesystem.
   Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una
   nuova voce per un file esistente con la funzione \func{link} (vedi
-  sez.~\ref{sec:file_link}) a file nel filesystem corrente.
+  sez.~\ref{sec:file_link}), a operare su file nel filesystem corrente.
   
 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una
@@ -516,13 +516,13 @@ nativo di diversi filesystem che sono in uso da anni, quello che gli avvicina
 di più è la famiglia di filesystem evolutasi a partire dal \textit{second
   extended filesystem}, o \acr{ext2}. Il filesystem \acr{ext2} ha subito un
 grande sviluppo e diverse evoluzioni, fra cui l'aggiunta del
-\textit{journaling} con \acr{ext3}, probabilmente ancora il filesystem più
-diffuso, ed una serie di ulteriori miglioramento con il successivo \acr{ext4},
-che sta iniziando a sostituirlo gradualmente. 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 questo paragrafo, l'inizio del 2012.}
+\textit{journaling} con il passaggio ad \acr{ext3}, che probabilmente è ancora
+il filesystem più diffuso, ed una serie di ulteriori miglioramenti con il
+successivo \acr{ext4}, che sta iniziando a sostituirlo gradualmente. 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 questo paragrafo, l'inizio del 2012.}
 
 Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
 dalle prime versioni del kernel e supporta tutte le caratteristiche di un
@@ -620,9 +620,9 @@ contenenti un gran numero di file.
 \label{sec:sys_file_config}
 
 Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file
-occorre prima rendere disponibile al sistema il filesystem su cui essi sono
-memorizzati; l'operazione di attivazione del filesystem è chiamata
-\textsl{montaggio}, per far questo in Linux si usa la funzione \funcd{mount},
+occorre rendere disponibile al sistema il filesystem su cui essi sono
+memorizzati. L'operazione di attivazione del filesystem è chiamata
+\textsl{montaggio} e per far questo in Linux si usa la funzione \funcd{mount},
 il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che
   usa la omonima \textit{system call} e non è portabile.}
 
@@ -725,8 +725,8 @@ forma della lista di parole chiave indicata con l'argomento \param{data},
 esistono pure alcune opzioni che si possono applicare in generale, anche se
 non è detto che tutti i filesystem le supportino, che si specificano tramite
 l'argomento \param{mountflags}.  L'argomento inoltre può essere utilizzato per
-modificare il comportamento della funzione, facendole compiere una operazione
-diversa (ad esempio un rimontaggio, invece che un montaggio).
+modificare il comportamento della funzione \func{mount}, facendole compiere
+una operazione diversa (ad esempio un rimontaggio, invece che un montaggio).
 
 In Linux \param{mountflags} deve essere un intero a 32 bit; fino ai kernel
 della serie 2.2.x i 16 più significativi avevano un valore riservato che
@@ -748,8 +748,8 @@ identificati dalle costanti riportate nell'elenco seguente:
   possibile montare una directory di un filesystem in un'altra directory,
   l'opzione è disponibile a partire dai kernel della serie 2.4. In questo caso
   verranno presi in considerazione solo gli argomenti \param{source}, che
-  stavolta indicherà la directory che si vuole montare (e non un file di
-  dispositivo) e \param{target} che indicherà la directory su cui verrà
+  stavolta indicherà la 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.
 
@@ -787,20 +787,19 @@ identificati dalle costanti riportate nell'elenco seguente:
   Fino al kernel 2.6.26 questo flag doveva essere usato da solo, in quanto il
   \textit{bind mount} continuava ad utilizzare le stesse opzioni del montaggio
   originale, dal 2.6.26 è stato introdotto il supporto per il cosiddetto
-  \textit{read-only bind mount} e viene onorata la presenza del flag
-  \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file sotto
-  \param{target} sia effettuabile esclusivamente in sola lettura.
+  \textit{read-only bind mount} e viene onorata 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.
 
   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:file_link}) ottenendo un qualcosa di analogo in cui si può
-  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 link simbolici (di cui parleremo in
-  sez.~\ref{sec:file_symlink}) che funziona correttamente anche all'intero di
-  un \textit{chroot} (argomento su cui torneremo in
-  sez.~\ref{sec:file_chroot}.  
+  sez.~\ref{sec:file_link}) 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 link simbolici (di cui parleremo in sez.~\ref{sec:file_symlink}) che
+  funziona correttamente anche all'intero di un \textit{chroot} (argomento su
+  cui torneremo in sez.~\ref{sec:file_chroot}).  
 \itindend{bind~mount}
 
 \item[\const{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
@@ -808,7 +807,7 @@ identificati dalle costanti riportate nell'elenco seguente:
   (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
-  con il comando \cmd{lsattr}.\footnote{questo avviene tramite delle opportune
+  con il comando \cmd{chattr}.\footnote{questo avviene tramite delle opportune
     \texttt{ioctl} (vedi sez.~\ref{sec:file_ioctl}).}
 
   Questo consente di ridurre al minimo il rischio di perdita dei dati delle
@@ -961,7 +960,7 @@ identificati dalle costanti riportate nell'elenco seguente:
   cambiandone le opzioni di montaggio in maniera atomica. 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 \param{data} che \param{mountflags}
+  il montaggio originale, mentre sia \param{data} che \param{mountflags}
   conterranno le nuove opzioni, \param{filesystemtype} viene ignorato.
 
   Qualunque opzione specifica del filesystem indicata con \param{data} può
@@ -982,14 +981,16 @@ identificati dalle costanti riportate nell'elenco seguente:
     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 cioè vengono ``\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.
+  Lo scopo dell'opzione è ottenere che tutti i successivi \itindex{bind~mount}
+  \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
+  \itindex{mount~point} \textit{mount point} della stessa condivisione, e la
+  sezione di albero di file vista al di sotto di ciascuno di essi sarà sempre
+  identica.
 
 \item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
   avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
@@ -1010,7 +1011,7 @@ identificati dalle costanti riportate nell'elenco seguente:
   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
+  \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
@@ -1045,13 +1046,13 @@ identificati dalle costanti riportate nell'elenco seguente:
   \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 disabilità la capacità di
-  eseguire dei \itindex{bind~mount} \textit{bind mount}. Si comporta cioè come
-  allo stesso modo di un \itindex{mount~point} \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 \itindex{bind~mount} \textit{bind
-    mount}.
+  Un \textit{mount point} marcato in questo modo disabilita la capacità di
+  eseguire dei \itindex{bind~mount} \textit{bind mount} del suo contenuto. Si
+  comporta cioè come allo stesso modo di un \itindex{mount~point}
+  \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
+  \itindex{bind~mount} \textit{bind mount}.
 
 \end{basedescript}
 
@@ -1181,13 +1182,24 @@ con un errore di \errcode{EAGAIN}, mentre in caso di filesystem occupato si
 sarebbe ricevuto \errcode{BUSY}.  Una volta marcato, se nel frattempo non
 viene fatto nessun uso del filesystem, ad una successiva chiamata con
 \const{MNT\_EXPIRE} questo verrà smontato. Questo flag consente di realizzare
-un meccanismo che smonti automaticamente i filesystem che restano inutilizzato
+un meccanismo che smonti automaticamente i filesystem che restano inutilizzati
 per un certo periodo di tempo.
 
-% Infine il flag \const{UMOUNT\_NOFOLLOW} impedisce l'uso di un link simbolico
-% per \param{target} evitando così che si possano passare ai programmi che
-% effettuano lo smontaggio dei filesystem per i quali è previsto la possibilità
-% di gestione da parte degli utenti con uno programma \acr{sgid} 
+Infine il flag \const{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se
+questo è un link simbolico (vedi sez.~\ref{sec:file_symlink}). 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
+FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
+  interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
+  di implementare le funzioni del \textit{Virtual File System} in user space,
+  così da rendere possibile agli utenti l'implementazione di un loro filesytem
+  qualunque (con applicazioni di grande interesse come il filesystem cifrato
+  \textit{encfs} o il filesystem di rete \textit{sshfs}).} che si possano
+passare ai programmi che effettuano lo smontaggio dei filesystem, che in
+genere sono privilegiati ma consentono di agire solo sui propri \textit{mount
+  point}, dei link simbolici che puntano ad altri \textit{mount point},
+ottenendo così la possibilità di smontare qualunque filesystem. 
+
 
 Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD,
   ma con una struttura diversa.} utili per ottenere in maniera diretta
@@ -1212,13 +1224,15 @@ informazioni riguardo al filesystem su cui si trova un certo file, sono
 \end{funcproto}
 
 Queste funzioni permettono di ottenere una serie di informazioni generali
-riguardo al filesystem su cui si trova il file specificato con un ; queste vengono
-restituite all'indirizzo \param{buf} di una struttura \struct{statfs} definita
-come in fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il
-filesystem in esame sono impostati a zero.  I valori del campo \var{f\_type}
-sono definiti per i vari filesystem nei relativi file di header dei sorgenti
-del kernel da costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in
-genere è il nome del filesystem stesso.
+riguardo al filesystem su cui si trova il file specificato con un
+\textit{pathname} per \func{statfs} e con un file descriptor (vedi
+sez.~\ref{sec:file_fd}) per \func{statfs}.  Le informazioni vengono restituite
+all'indirizzo \param{buf} di una struttura \struct{statfs} definita come in
+fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il filesystem in
+esame sono impostati a zero.  I valori del campo \var{f\_type} sono definiti
+per i vari filesystem nei relativi file di header dei sorgenti del kernel da
+costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in genere è il nome
+del filesystem stesso.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1235,15 +1249,24 @@ file \conffile{/etc/fstab} ed \conffile{/etc/mtab}, che convenzionalmente sono
 usati in quasi tutti i sistemi unix-like per mantenere rispettivamente le
 informazioni riguardo ai filesystem da montare e a quelli correntemente
 montati. Le funzioni servono a leggere il contenuto di questi file in
-opportune strutture \struct{fstab} e \struct{mntent}, e, per
-\conffile{/etc/mtab} per inserire e rimuovere le voci presenti nel file.
-
-In generale si dovrebbero usare queste funzioni (in particolare quelle
-relative a \conffile{/etc/mtab}), quando si debba scrivere un programma che
-effettua il montaggio di un filesystem; in realtà in questi casi è molto più
-semplice invocare direttamente il programma \cmd{mount}, per cui ne
-tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
-\cite{glibc} per la documentazione completa.
+opportune strutture \struct{fstab} e \struct{mntent}, e, nel caso di
+\conffile{/etc/mtab}, per inserire e rimuovere le voci presenti nel file.
+
+In generale si dovrebbero usare queste funzioni, in particolare quelle
+relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
+effettua il montaggio di un filesystem. In realtà in questi casi è molto più
+semplice invocare direttamente il programma \cmd{mount}. Inoltre l'uso stesso
+di \conffile{/etc/mtab} è considerato una pratica obsoleta, in quanto se non
+aggiornato correttamente (cosa che è impossibile se la radice è montata in
+sola lettura) il suo contenuto diventa fuorviante.
+
+Pe questo motivo il suo utilizzo viene deprecato ed in molti casi viene già
+oggi sostituito da un link simbolico a \procfile{/proc/mounts}, che contiene
+una versione degli stessi contenuti (vale a dire l'elenco dei filesystem
+montati) generata direttamente dal kernel, e quindi sempre disponibile e
+sempre aggiornata. Per questo motivo tralasceremo la trattazione, di queste
+funzioni, rimandando al manuale delle \acr{glibc} \cite{glibc} per la
+documentazione completa.
 
 % TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
 % TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...) 
@@ -1255,11 +1278,11 @@ Come già accennato in sez.~\ref{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 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 e gli effetti delle varie funzioni.
+link simbolici e diretti, per la gestione e la lettura delle directory.  In
+particolare ci soffermeremo sulle conseguenze che derivano dalla struttura
+generica di un qualunque filesystem illustrata in
+sez.~\ref{sec:file_filesystem} per quanto attiene il comportamento e gli
+effetti delle varie funzioni.
 
 
 \subsection{Le funzioni \func{link} e \func{unlink}}
@@ -1271,9 +1294,9 @@ 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 l'architettura del sistema riguardo
-la gestione dei file ci sono due metodi sostanzialmente diversi per fare
-questa operazione.
+usualmente chiamati ``\textit{link}''; ma data l'architettura del sistema
+riguardo la gestione dei file ci sono due metodi sostanzialmente diversi per
+fare questa operazione.
 
 Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un
 file su disco avviene passando attraverso il suo \itindex{inode}
@@ -1283,18 +1306,19 @@ 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 \textit{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
+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 associazioni diverse allo stesso \itindex{inode}
-\textit{inode} effettuate tramite ``etichette'' diverse in directory
-diverse. Si noti anche che nessuno di questi nomi viene ad assumere una
-particolare preferenza o originalità rispetto agli altri, in quanto tutti
-fanno comunque riferimento allo stesso \itindex{inode} \textit{inode}.
+\textit{inode} effettuate tramite ``etichette'' diverse (voci, nella
+nomenclatura di sez.~\ref{sec:file_filesystem}) in directory diverse. Si noti
+anche che nessuno di questi nomi viene ad assumere una particolare preferenza
+o originalità rispetto agli altri, in quanto tutti fanno comunque riferimento
+allo stesso \itindex{inode} \textit{inode}.
 
 Per aggiungere ad una directory una voce che faccia riferimento ad un
 \itindex{inode} \textit{inode} già esistente si utilizza la funzione
-\funcd{link}; si suole chiamare questo tipo di associazione un collegamento
-diretto, o \textit{hard link}.  Il prototipo della funzione è il seguente:
+\funcd{link}, e si suole chiamare questo tipo di associazione un collegamento
+diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:
 
 \begin{funcproto}{ 
 \fhead{unistd.h}
@@ -1304,19 +1328,19 @@ diretto, o \textit{hard link}.  Il prototipo della funzione è il seguente:
 {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{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
-    riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
-    \textit{mount point}.
-  \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
-    \param{newpath} non supporta i link diretti o è una directory.
   \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
     esiste già.
   \item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il
     numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
     sez.~\ref{sec:sys_limits}).
-  \end{errlist} ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG},
-  \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, \errval{EROFS},
-  \errval{ELOOP}, \errval{ENOSPC}, \errval{EIO} nel loro significato
+  \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
+    \param{newpath} non supporta i link diretti o è una directory.
+  \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
+    riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
+    \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{funcproto}
 
@@ -1327,12 +1351,12 @@ 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 sez.~\ref{sec:file_stat}) aggiungendo il
-nuovo nome ai precedenti. Si noti che uno stesso file può essere così chiamato
+nuovo nome ai precedenti. In questo modo lo stesso file può essere chiamato
 con vari nomi in diverse directory.
 
 Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
 collegamento diretto è possibile solo se entrambi i \textit{pathname} sono
-nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti
+nello stesso filesystem. Inoltre il filesystem deve supportare i collegamenti
 diretti (il meccanismo non è disponibile ad esempio con il filesystem
 \acr{vfat} di Windows). In realtà la funzione ha un ulteriore requisito, e
 cioè che non solo che i due file siano sullo stesso filesystem, ma anche che
@@ -1346,9 +1370,9 @@ 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 l'esempio mostrato in
-sez.~\ref{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
+sez.~\ref{sec:file_symlink}, dove riprenderemo il discorso) che molti
+programmi non sono in grado di gestire e la cui rimozione diventerebbe
+piuttosto complicata (in genere per questo tipo di errori occorre eseguire il
 programma \cmd{fsck} per riparare il filesystem).
 
 Data la pericolosità di questa operazione e la disponibilità dei link
@@ -1360,22 +1384,24 @@ disabilitata, e al tentativo di creare un link diretto ad una directory la
 funzione \func{link} restituisce l'errore \errcode{EPERM}.
 
 Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
-\textit{hard link} ad un link simbolico. In questo caso lo standard POSIX
-prevederebbe che quest'ultimo venga risolto e che il collegamento sia
-effettuato rispetto al file cui esso punta, e che venga riportato un errore
-qualora questo non esista o non sia un file. Questo era anche il comportamento
-iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la
-  precisione il comportamento era quello previsto dallo standard POSIX fino al
-  kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
-  durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento
-  attuale fino ad oggi (per riferimento si veda
+\textit{hard link} ad un link simbolico. In questo caso lo standard
+POSIX.1-2001 prevederebbe che quest'ultimo venga risolto e che il collegamento
+sia effettuato rispetto al file cui esso punta, e che venga riportato un
+errore qualora questo non esista o non sia un file. Questo era anche il
+comportamento iniziale di Linux ma a partire dai kernel della serie
+2.0.x\footnote{per la precisione il comportamento era quello previsto dallo
+  standard POSIX fino al kernel di sviluppo 1.3.56, ed è stato temporaneamente
+  ripristinato anche durante lo sviluppo della serie 2.1.x, per poi tornare al
+  comportamento attuale fino ad oggi (per riferimento si veda
   \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento
 che non segue più lo standard per cui l'\textit{hard link} viene creato
-rispetto al link simbolico, e non al file cui questo punta.
+rispetto al link simbolico, e non al file cui questo punta. La revisione
+POSIX.1-2008 lascia invece il comportamento dipendente dall'implementazione,
+cosa che rende Linux aderente allo standard.
 
-La ragione di questa differenza rispetto allo standard, presente anche in
-altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
-riferimento anche ad un file non esistente o a una directory, per i quali
+La ragione di questa differenza rispetto al vecchio standard, presente anche
+in altri sistemi unix-like, sono dovute al fatto che un link simbolico può
+fare riferimento anche ad un file non esistente o a una directory, per i quali
 l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
 link simbolico è stata ritenuta una scelta scorretta nella progettazione
 dell'interfaccia.  Infatti se non ci fosse il comportamento adottato da Linux
@@ -1385,10 +1411,10 @@ destinazione. Invece evitando di seguire lo standard l'operazione diventa
 possibile, ed anche il comportamento della funzione risulta molto più
 comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
   link} rispetto alla destinazione di un link simbolico è sempre possibile
-farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
-  standard possa causare problemi, come nell'esempio descritto nell'articolo
-  citato nella nota precedente, a programmi che non si aspettano questa
-  differenza rispetto allo standard POSIX.}
+farlo direttamente.\footnote{ciò non toglie che questo comportamento possa
+  causare problemi, come nell'esempio descritto nell'articolo citato nella
+  nota precedente, a programmi che non si aspettano questa differenza rispetto
+  allo standard POSIX.}
 
 La rimozione di un file (o più precisamente della voce che lo referenzia
 all'interno di una directory) si effettua con la funzione \funcd{unlink}; il