X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileio.tex;h=6abde2f0292614fe2c0e3d35d528521055222baa;hp=ba66a3539e174655c0c7d8df39f2687f41d1307e;hb=04a547df13e4c672d95e1060e1ada9ae2e1fcb2f;hpb=4d46f47e3a0e08440812b334f79489d92814e6d2;ds=sidebyside

diff --git a/fileio.tex b/fileio.tex
index ba66a35..6abde2f 100644
--- a/fileio.tex
+++ b/fileio.tex
@@ -14,9 +14,9 @@
 
 Esamineremo in questo capitolo le due interfacce di programmazione che
 consentono di gestire i dati mantenuti nei file. Cominceremo con quella nativa
-del sistema, detta dei \itindex{file~descriptor} \textit{file descriptor}, che
-viene fornita direttamente dalle \textit{system call} e che non prevede
-funzionalità evolute come la bufferizzazione o funzioni di lettura o scrittura
+del sistema, detta dei \textit{file descriptor}, che viene fornita
+direttamente dalle \textit{system call} e che non prevede funzionalità evolute
+come la bufferizzazione o funzioni di lettura o scrittura
 formattata. Esamineremo poi anche l'interfaccia definita dallo standard ANSI
 C, che viene chiamata dei \textit{file stream} o anche più brevemente degli
 \textit{stream}. Per entrambe dopo una introduzione alle caratteristiche
@@ -468,16 +468,15 @@ Si è riportato in tab.~\ref{tab:open_time_flag} l'elenco dei flag delle
   esistono con Linux.}  Uno di questi, \const{O\_EXCL}, ha senso solo se usato
 in combinazione a \const{O\_CREAT} quando si vuole creare un nuovo file per
 assicurarsi che questo non esista di già, e lo si usa spesso per creare i
-cosiddetti \index{file!di lock} ``\textsl{file di lock}'' (vedi
-sez.~\ref{sec:ipc_file_lock}). Si tenga presente che questa opzione è
-supportata su NFS solo a partire da NFSv3 e con il kernel 2.6, nelle versioni
-precedenti la funzionalità viene emulata controllando prima l'esistenza del
-file per cui usarla per creare \index{file!di lock} un file di lock potrebbe
-dar luogo a una \textit{race condition}.\footnote{un file potrebbe venir
-  creato fra il controllo la successiva apertura con \const{O\_CREAT}, la cosa
-  si può risolvere comunque creando un file con un nome univoco ed usando la
-  funzione \func{link} per creare il \index{file!di lock} file di lock, (vedi
-  sez.~\ref{sec:ipc_file_lock}).}
+cosiddetti ``\textsl{file di lock}'' (vedi sez.~\ref{sec:ipc_file_lock}). Si
+tenga presente che questa opzione è supportata su NFS solo a partire da NFSv3
+e con il kernel 2.6, nelle versioni precedenti la funzionalità viene emulata
+controllando prima l'esistenza del file per cui usarla per creare un file di
+lock potrebbe dar luogo a una \textit{race condition}.\footnote{un file
+  potrebbe venir creato fra il controllo la successiva apertura con
+  \const{O\_CREAT}, la cosa si può risolvere comunque creando un file con un
+  nome univoco ed usando la funzione \func{link} per creare il file di lock,
+  (vedi sez.~\ref{sec:ipc_file_lock}).}
 
 Se si usa \const{O\_EXCL} senza \const{O\_CREAT} il comportamento è
 indefinito.  Nella creazione di un file con \const{O\_CREAT} occorre sempre
@@ -1561,14 +1560,14 @@ filesystem su cui il file ad esso corrispondente si trova.
 \itindbeg{at-functions}
 
 Un problema generale che si pone con l'uso della funzione \func{open}, così
-come per le altre funzioni che prendono come argomenti dei
-\itindsub{pathname}{relativo} \textit{pathname} relativi, è la possibilità,
-quando un \textit{pathname} relativo non fa riferimento ad un file posto
-direttamente nella directory di lavoro corrente, che alcuni dei componenti del
-\textit{pathname} vengano modificati in parallelo alla chiamata a \func{open},
-cosa che lascia aperta la possibilità di una \textit{race condition} in cui
-c'è spazio per un \textit{symlink attack} (si ricordi quanto visto per
-\func{access} in sez.~\ref{sec:file_perm_management}).
+come per le altre funzioni che prendono come argomenti dei \textit{pathname}
+relativi, è la possibilità, quando un \textit{pathname} relativo non fa
+riferimento ad un file posto direttamente nella directory di lavoro corrente,
+che alcuni dei componenti del \textit{pathname} vengano modificati in
+parallelo alla chiamata a \func{open}, cosa che lascia aperta la possibilità
+di una \textit{race condition} in cui c'è spazio per un \textit{symlink
+  attack} (si ricordi quanto visto per \func{access} in
+sez.~\ref{sec:file_perm_management}).
 
 Inoltre come già accennato, la directory di lavoro corrente è una proprietà
 del singolo processo; questo significa che quando si lavora con i
@@ -1581,27 +1580,27 @@ Solaris, a fianco delle normali funzioni che operano sui file (come
 \func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
 funzioni, dette anche ``\textit{at-functions}'' in quanto contraddistinte dal
 suffisso \texttt{at}, che permettono l'apertura di un file (o le rispettive
-altre operazioni) usando un \itindsub{pathname}{relativo} \textit{pathname}
-relativo ad una directory specificata.\footnote{l'introduzione è avvenuta su
-  proposta dello sviluppatore principale della \acr{glibc} Urlich Drepper e le
-  corrispondenti \textit{system call} sono state inserite nel kernel a partire
-  dalla versione 2.6.16, in precedenza era disponibile una emulazione che, sia
-  pure con prestazioni inferiori, funzionava facendo ricorso all'uso del
-  filesystem \textit{proc} con l'apertura del file attraverso il riferimento a
+altre operazioni) usando un \textit{pathname} relativo ad una directory
+specificata.\footnote{l'introduzione è avvenuta su proposta dello sviluppatore
+  principale della \acr{glibc} Urlich Drepper e le corrispondenti
+  \textit{system call} sono state inserite nel kernel a partire dalla versione
+  2.6.16, in precedenza era disponibile una emulazione che, sia pure con
+  prestazioni inferiori, funzionava facendo ricorso all'uso del filesystem
+  \textit{proc} con l'apertura del file attraverso il riferimento a
   \textit{pathname} del tipo di \texttt{/proc/self/fd/dirfd/relative\_path}.}
 Benché queste funzioni non siano presenti negli standard tradizionali esse
-sono state adottate da altri sistemi unix-like come Solaris, i vari BSD, fino ad
-essere incluse in una recente revisione (la POSIX.1-2008) dello standard
+sono state adottate da altri sistemi unix-like come Solaris, i vari BSD, fino
+ad essere incluse in una recente revisione (la POSIX.1-2008) dello standard
 POSIX.1. Con la \acr{glibc} per l'accesso a queste funzioni è necessario
 definire la macro \macro{\_ATFILE\_SOURCE}.
 
 L'uso di queste funzioni prevede una apertura iniziale della directory che
-sarà la base della risoluzione dei \itindsub{pathname}{relativo}
-\textit{pathname} relativi che verranno usati in seguito, dopo di che si dovrà
-passare il relativo file descriptor alle varie funzioni che useranno quella
-directory come punto di partenza per la risoluzione. In questo modo, anche
-quando si lavora con i \itindex{thread} \textit{thread}, si può mantenere una
-directory di lavoro diversa per ciascuno di essi.
+sarà la base della risoluzione dei \textit{pathname} relativi che verranno
+usati in seguito, dopo di che si dovrà passare il relativo file descriptor
+alle varie funzioni che useranno quella directory come punto di partenza per
+la risoluzione. In questo modo, anche quando si lavora con i \itindex{thread}
+\textit{thread}, si può mantenere una directory di lavoro diversa per ciascuno
+di essi.
 
 Questo metodo, oltre a risolvere i problemi di \textit{race condition},
 consente anche di ottenere aumenti di prestazioni significativi quando si
@@ -1628,17 +1627,16 @@ esame la nuova funzione di sistema \funcd{openat}, avremo il prototipo:
   \func{open}, ed in più:
   \begin{errlist}
   \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
-  \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
-    \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
+  \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+    ma \param{dirfd} fa riferimento ad un file.
    \end{errlist}
 }  
 \end{funcproto}
 
 Il comportamento delle nuove funzioni è del tutto analogo a quello delle
 corrispettive classiche, con la sola eccezione del fatto che se fra i loro
-argomenti si utilizza un \itindsub{pathname}{relativo} \textit{pathname}
-relativo questo sarà risolto rispetto alla directory indicata
-da \param{dirfd}. Qualora invece si usi un \itindsub{pathname}{assoluto}
+argomenti si utilizza un \textit{pathname} relativo questo sarà risolto
+rispetto alla directory indicata da \param{dirfd}. Qualora invece si usi un
 \textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
 se per \param{dirfd} si usa il valore speciale \const{AT\_FDCWD}, la
 risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
@@ -1653,8 +1651,8 @@ errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
 particolare si avrà un errore di \errcode{EBADF} se esso non è un file
 descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa
 riferimento ad una directory, tranne il caso in cui si sia specificato un
-\itindsub{pathname}{assoluto} \textit{pathname} assoluto, nel qual caso, come
-detto, il valore di \param{dirfd} sarà completamente ignorato.
+\textit{pathname} assoluto, nel qual caso, come detto, il valore
+di \param{dirfd} sarà completamente ignorato.
 
 \begin{table}[htb]
   \centering
@@ -1736,8 +1734,8 @@ che \func{lchown}; il suo prototipo è:
   \begin{errlist}
   \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
   \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
-  \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
-    \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file. 
+  \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+    ma \param{dirfd} fa riferimento ad un file.
   \end{errlist}
 }  
 \end{funcproto}
@@ -1765,8 +1763,8 @@ prima di queste è \funcd{faccessat}, ed il suo prototipo è:
   \begin{errlist}
   \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
   \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
-  \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
-    \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file. 
+  \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+    ma \param{dirfd} fa riferimento ad un file.
   \end{errlist}
 }  
 \end{funcproto}
@@ -1798,8 +1796,8 @@ alla funzione di comportarsi sia come analogo di \func{unlink} che di
   \begin{errlist}
   \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
   \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
-  \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
-    \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
+  \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+    ma \param{dirfd} fa riferimento ad un file.
   \end{errlist}
 }  
 \end{funcproto}