Correzioni da parte di D. Masini
[gapil.git] / filedir.tex
index d7cfa6f9c77cb87f4a051ff65bdb44b89bc738d1..f7ce34067ad456b55f0d582acdb8b57323f15c9c 100644 (file)
@@ -40,7 +40,7 @@ fare questa operazione.
 
 Come spiegato in \secref{sec:file_filesystem} l'accesso al contenuto di un
 file su disco avviene attraverso il suo inode\index{inode}, e il nome che si
-trova in una directory è solo unetichetta associata ad un puntatore a che fa
+trova in una directory è solo un'etichetta associata ad un puntatore a che fa
 riferimento al suddetto inode.
 
 Questo significa che la realizzazione di un link è immediata in quanto uno
@@ -142,14 +142,14 @@ del file o proprietari della directory (o root, per cui nessuna delle
 restrizioni è applicata).
 
 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
-della nome dalla directory e l'incremento/decremento del numero di riferimenti
+del nome dalla directory e l'incremento/decremento del numero di riferimenti
 nell'inode devono essere effettuati in maniera atomica (si veda
 \secref{sec:proc_atom_oper}) senza possibili interruzioni fra le due
-operazioni, per questo entrambe queste funzioni sono realizzate tramite una
+operazioni. Per questo entrambe queste funzioni sono realizzate tramite una
 singola system call.
 
 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
-i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
+i riferimenti ad esso sono stati cancellati: solo quando il \textit{link
   count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
 questo però si aggiunge un'altra condizione, e cioè che non ci siano processi
 che abbiano detto file aperto.  
@@ -264,10 +264,10 @@ ad una directory.
 
 Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
-come avviene in altri sistemi operativi, dei file speciali che contengono il
+come avviene in altri sistemi operativi, dei file speciali che contengono
 semplicemente il riferimento ad un altro file (o directory). In questo modo è
-possibile effettuare link anche attraverso filesystem diversi, a file posti
-in filesystem che non supportano i link diretti, a delle directory, ed anche a
+possibile effettuare link anche attraverso filesystem diversi, a file posti in
+filesystem che non supportano i link diretti, a delle directory, ed anche a
 file che non esistono ancora.
 
 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
@@ -506,7 +506,7 @@ nuovi file nella directory.
 \label{sec:file_mknod}
 
 Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in
-\secref{sec:file_file_types} abbiamo visto però che il sistema preveda pure
+\secref{sec:file_file_types} abbiamo visto però che il sistema prevede pure
 degli altri tipi di file, come i file di dispositivo e le fifo (i socket sono
 un caso a parte, che vedremo in \secref{cha:socket_intro}). 
 
@@ -609,7 +609,7 @@ struttura \var{struct dirent}.
 A ciascun processo è associato ad una directory nel filesystem che è chiamata
 directory corrente o directory di lavoro (\textit{current working directory})
 che è quella a cui si fa riferimento quando un filename è espresso in forma
-relativa, dove il relativa fa riferimento appunto a questa directory.
+relativa, dove il ``relativa'' fa riferimento appunto a questa directory.
 
 Quando un utente effettua il login questa directory viene settata alla
 \textit{home directory} del suo account. Il comando \cmd{cd} della shell
@@ -664,9 +664,9 @@ Una seconda funzione simile 
 sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la sola
 differenza che essa ritorna il valore della variabile di ambiente \macro{PWD},
 che essendo costruita dalla shell può contenere un pathname comprendente anche
-con dei link simbolici. Usando \func{getcwd} infatti, essendo il
-pathname ricavato risalendo all'indietro l'albero della directory, si
-perderebbe traccia di ogni passaggio attraverso eventuali link simbolici.
+dei link simbolici. Usando \func{getcwd} infatti, essendo il pathname ricavato
+risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
+passaggio attraverso eventuali link simbolici.
 
 Per cambiare la directory di lavoro corrente si può usare la funzione
 \func{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta
@@ -764,12 +764,13 @@ la prima valida delle seguenti:
 \end{itemize*}
 
 In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
-ottere un nome duplicato, nulla assicura che un altro processo non possa avere
-creato, fra l'ottenimento del nome e l'apertura del file, un altro file con lo
-stesso nome; per questo motivo quando si usa il nome ottenuto da una di queste
-funzioni occorre sempre aprire il nuovo file in modalità di esclusione (cioè
-con l'opzione \macro{O\_EXCL} per i file descriptor o con il flag \code{x} per
-gli stream) che fa fallire l'apertura in caso il file sia già esistente.
+ottenere un nome duplicato, nulla assicura che un altro processo non possa
+avere creato, fra l'ottenimento del nome e l'apertura del file, un altro file
+con lo stesso nome; per questo motivo quando si usa il nome ottenuto da una di
+queste funzioni occorre sempre aprire il nuovo file in modalità di esclusione
+(cioè con l'opzione \macro{O\_EXCL} per i file descriptor o con il flag
+\code{x} per gli stream) che fa fallire l'apertura in caso il file sia già
+esistente.
 
 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
 POSIX definisce la funzione \func{tempfile}, il cui prototipo è:
@@ -789,9 +790,9 @@ POSIX definisce la funzione \func{tempfile}, il cui prototipo 
 \noindent essa restituisce direttamente uno stream già aperto (in modalità
 \code{r+b}, si veda \secref{sec:file_fopen}) e pronto per l'uso, che viene
 automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo
-standard non specifica in quale directory verrà aperto il file, ma \acr{glibc}
-prima tentano con \macro{P\_tmpdir} e poi con \file{/tmp}. Questa funzione è
-rientrante e non soffre di problemi di \textit{race condition}.
+standard non specifica in quale directory verrà aperto il file, ma le
+\acr{glibc} prima tentano con \macro{P\_tmpdir} e poi con \file{/tmp}. Questa
+funzione è rientrante e non soffre di problemi di \textit{race condition}.
 
 Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
 caso si possono usare le vecchie funzioni \func{mktemp} e \func{mkstemp} che
@@ -985,7 +986,7 @@ riportato in \ntab.
     \macro{S\_ISSOCK(m)} & socket \\
     \hline    
   \end{tabular}
-  \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h})}
+  \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
   \label{tab:file_type_macro}
 \end{table}
 
@@ -1038,7 +1039,7 @@ un'opportuna combinazione.
     \hline    
   \end{tabular}
   \caption{Costanti per l'identificazione dei vari bit che compongono il campo
-    \var{st\_mode} (definite in \file{sys/stat.h})}
+    \var{st\_mode} (definite in \file{sys/stat.h}).}
   \label{tab:file_mode_flags}
 \end{table}
 
@@ -1065,12 +1066,12 @@ i trasferimenti sui file (che 
 per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
 dimensione inferiore sarebbe inefficiente.
 
-Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
-che corrisponda all'occupazione dello spazio su disco per via della possibile
-esistenza dei cosiddetti \textit{holes} (letteralmente \textsl{buchi}) che
-si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
-una \func{lseek} (vedi \secref{sec:file_lseek}) oltre la sua conclusione
-corrente.
+Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è
+detto che corrisponda all'occupazione dello spazio su disco per via della
+possibile esistenza dei cosiddetti \textit{holes} (letteralmente
+\textsl{buchi}) che si formano tutte le volte che si va a scrivere su un file
+dopo aver eseguito una \func{lseek} (vedi \secref{sec:file_lseek}) oltre la
+sua fine.
 
 In questo caso si avranno risultati differenti a seconda del modo in cui si
 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
@@ -1149,7 +1150,7 @@ riportato un esempio delle funzioni che effettuano cambiamenti su di essi.
     \func{utime} & \cmd{-c} \\ 
     \hline
   \end{tabular}
-  \caption{I tre tempi associati a ciascun file}
+  \caption{I tre tempi associati a ciascun file.}
   \label{tab:file_file_times}
 \end{table}
 
@@ -1556,12 +1557,12 @@ usati per guadagnare privilegi non consentiti (l'argomento 
 dettaglio in \secref{sec:proc_perms}).
 
 La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con
-il comando \cmd{ls -l}, che una lettera \cmd{s} al posto della \cmd{x} in
-corrispondenza dei permessi di utente o gruppo. La stessa lettera \cmd{s} può
-essere usata nel comando \cmd{chmod} per settare questi bit. Infine questi bit
-possono essere controllati all'interno di \var{st\_mode} con l'uso delle due
-costanti \macro{S\_ISUID} e \macro{S\_IGID}, i cui valori sono riportati in
-\tabref{tab:file_mode_flags}.
+il comando \cmd{ls -l}, che visualizza una lettera \cmd{s} al posto della
+\cmd{x} in corrispondenza dei permessi di utente o gruppo. La stessa lettera
+\cmd{s} può essere usata nel comando \cmd{chmod} per settare questi bit.
+Infine questi bit possono essere controllati all'interno di \var{st\_mode} con
+l'uso delle due costanti \macro{S\_ISUID} e \macro{S\_IGID}, i cui valori sono
+riportati in \tabref{tab:file_mode_flags}.
 
 Gli stessi bit vengono ad assumere in significato completamente diverso per le
 directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare
@@ -1570,7 +1571,7 @@ veda \secref{sec:file_ownership} per una spiegazione dettagliata al
 proposito).
 
 Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione mutuata
-da SVR4. Il caso in cui un file ha il bit \acr{sgid} settato senza che lo sia
+da SVr4. Il caso in cui un file ha il bit \acr{sgid} settato senza che lo sia
 anche il corrispondente bit di esecuzione viene utilizzato per attivare per
 quel file il \textit{mandatory locking} (argomento che affronteremo in
 dettagliopiù avanti in \secref{sec:file_mand_locking}).
@@ -1655,7 +1656,7 @@ automaticamente propagato, restando coerente a quello della directory di
 partenza, in tutte le sottodirectory. La semantica SVr4 offre la possibilità
 di scegliere, ma per ottenere lo stesso risultato di coerenza che si ha con
 BSD necessita che per le nuove directory venga anche propagato anche il bit
-\acr{sgid}. Questo è il comportamento di default di \func{mkdir}, ed é in
+\acr{sgid}. Questo è il comportamento di default di \func{mkdir}, ed è in
 questo modo ad esempio che Debian assicura che le sottodirectory create nelle
 home di un utente restino sempre con il \acr{gid} del gruppo primario dello
 stesso.
@@ -1713,7 +1714,7 @@ contrario (o di errore) ritorna -1.
     \hline
   \end{tabular}
   \caption{Valori possibile per il parametro \var{mode} della funzione 
-    \func{access}}
+    \func{access}.}
   \label{tab:file_access_mode_val}
 \end{table}
 
@@ -1814,7 +1815,7 @@ particolare:
 
 Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
   caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
-misura di sicurezza, volta ad scongiurare l'abuso dei bit \acr{suid} e
+misura di sicurezza, volta a scongiurare l'abuso dei bit \acr{suid} e
 \acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un
 processo che non appartenga all'amministratore scriva su un file. In questo
 modo anche se un utente malizioso scopre un file \acr{suid} su cui può
@@ -1897,7 +1898,7 @@ cambiare il gruppo dei file che gli appartengono solo se il nuovo gruppo 
 suo gruppo primario o uno dei gruppi a cui appartiene.
 
 La funzione \func{chown} segue i link simbolici, per operare direttamente su
-in link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
+un link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
   versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
   allora questo comportamento è stato assegnato alla funzione \func{lchown},
   introdotta per l'occasione, ed è stata creata una nuova system call per