Reindicizzazione
[gapil.git] / fileio.tex
index a963c9622103bdf58b2ae3d4246dcbe0951b0056..77769ece37748d09c809388d4df7af03f8be0e41 100644 (file)
@@ -29,13 +29,13 @@ ultime le caratteristiche più avanzate.
 
 
 Come visto in sez.~\ref{sec:file_vfs_work} il kernel mette a disposizione
 
 
 Come visto in sez.~\ref{sec:file_vfs_work} il kernel mette a disposizione
-tramite il \itindex{Virtual~File~System} \textit{Virtual File System} una
-serie di \textit{system call} che consentono di operare sui file in maniera
-generale. Abbiamo trattato quelle relative alla gestione delle proprietà dei
-file nel precedente capitolo, vedremo quelle che si applicano al contenuto dei
-file in questa sezione, iniziando con una breve introduzione sull'architettura
-dei \textit{file descriptor} per poi trattare le funzioni di base e le
-modalità con cui consentono di gestire i dati memorizzati sui file.
+tramite il \textit{Virtual File System} una serie di \textit{system call} che
+consentono di operare sui file in maniera generale. Abbiamo trattato quelle
+relative alla gestione delle proprietà dei file nel precedente capitolo,
+vedremo quelle che si applicano al contenuto dei file in questa sezione,
+iniziando con una breve introduzione sull'architettura dei \textit{file
+  descriptor} per poi trattare le funzioni di base e le modalità con cui
+consentono di gestire i dati memorizzati sui file.
 
 
 \subsection{I \textit{file descriptor}}
 
 
 \subsection{I \textit{file descriptor}}
@@ -53,10 +53,10 @@ comunicazione con il kernel che renda possibile operare su di esso. Questo si
 fa aprendo il file con la funzione \func{open} (vedi
 sez.~\ref{sec:file_open_close}) che provvederà a localizzare \itindex{inode}
 l'\textit{inode} del file e inizializzare i puntatori che rendono disponibili
 fa aprendo il file con la funzione \func{open} (vedi
 sez.~\ref{sec:file_open_close}) che provvederà a localizzare \itindex{inode}
 l'\textit{inode} del file e inizializzare i puntatori che rendono disponibili
-le funzioni che il \itindex{Virtual~File~System} VFS mette a disposizione
-(quelle di tab.~\ref{tab:file_file_operations}). Una volta terminate le
-operazioni, il file dovrà essere chiuso, e questo chiuderà il canale di
-comunicazione impedendo ogni ulteriore operazione.
+le funzioni che il VFS mette a disposizione (quelle di
+tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
+file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
+impedendo ogni ulteriore operazione.
 
 All'interno di ogni processo i file aperti sono identificati da un numero
 intero non negativo, che viene chiamato \textit{file descriptor}.  Quando un
 
 All'interno di ogni processo i file aperti sono identificati da un numero
 intero non negativo, che viene chiamato \textit{file descriptor}.  Quando un
@@ -834,9 +834,9 @@ per i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che
 non supportano questa funzione, come ad esempio per i file di
 terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
   ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
 non supportano questa funzione, come ad esempio per i file di
 terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
   ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
-POSIX però non specifica niente in proposito. Inoltre alcuni
-\index{file!speciali} file speciali, ad esempio \file{/dev/null}, non causano
-un errore ma restituiscono un valore indefinito.
+POSIX però non specifica niente in proposito. Inoltre alcuni file speciali, ad
+esempio \file{/dev/null}, non causano un errore ma restituiscono un valore
+indefinito.
 
 \itindbeg{sparse~file} 
 \index{file!\textit{hole}|(} 
 
 \itindbeg{sparse~file} 
 \index{file!\textit{hole}|(} 
@@ -1490,8 +1490,8 @@ prototipi sono:
 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
   caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
   caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
-  \item[\errcode{EINVAL}] \param{fd} è un \index{file!speciali} file speciale
-    che non supporta la sincronizzazione.
+  \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
+    sincronizzazione.
   \end{errlist}
   ed inoltre \errval{EBADF}, \errval{EIO} e \errval{EROFS} nel loro
   significato generico.}
   \end{errlist}
   ed inoltre \errval{EBADF}, \errval{EIO} e \errval{EROFS} nel loro
   significato generico.}
@@ -1560,19 +1560,18 @@ 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
 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 \index{directory~di~lavoro} 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 \itindex{race~condition} \textit{race condition} in cui c'è spazio per
-un \itindex{symlink~attack} \textit{symlink attack} (si ricordi quanto visto
-per \func{access} in sez.~\ref{sec:file_perm_management}).
-
-Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
-corrente è una proprietà del singolo processo; questo significa che quando si
-lavora con i \itindex{thread} \textit{thread} essa sarà la stessa per tutti,
-ma esistono molti casi in cui sarebbe invece utile che ogni singolo
-\itindex{thread} \textit{thread} avesse la sua \index{directory~di~lavoro}
-directory di lavoro.
+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 \itindex{race~condition}
+\textit{race condition} in cui c'è spazio per un \itindex{symlink~attack}
+\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
+\textit{thread} essa sarà la stessa per tutti, ma esistono molti casi in cui
+sarebbe invece utile che ogni singolo \textit{thread} avesse la sua directory
+di lavoro.
 
 Per risolvere questi problemi, riprendendo una interfaccia già presente in
 Solaris, a fianco delle normali funzioni che operano sui file (come
 
 Per risolvere questi problemi, riprendendo una interfaccia già presente in
 Solaris, a fianco delle normali funzioni che operano sui file (come
@@ -1599,7 +1598,7 @@ sarà la base della risoluzione dei \itindsub{pathname}{relativo}
 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
 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
-\index{directory~di~lavoro} directory di lavoro diversa per ciascuno di essi.
+directory di lavoro diversa per ciascuno di essi.
 
 Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
 \textit{race condition}, consente anche di ottenere aumenti di prestazioni
 
 Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
 \textit{race condition}, consente anche di ottenere aumenti di prestazioni
@@ -1620,8 +1619,7 @@ esame la nuova funzione di sistema \funcd{openat}, avremo il prototipo:
 \fhead{fcntl.h}
 \fdecl{int openat(int dirfd, const char *pathname, int flags)}
 \fdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t mode)}
 \fhead{fcntl.h}
 \fdecl{int openat(int dirfd, const char *pathname, int flags)}
 \fdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t mode)}
-\fdesc{Apre un file a partire da una directory di \index{directory~di~lavoro}
-  lavoro.} 
+\fdesc{Apre un file a partire da una directory di lavoro.} 
 }
 
 {La funzione ritorna gli stessi valori e gli stessi codici di errore di
 }
 
 {La funzione ritorna gli stessi valori e gli stessi codici di errore di
@@ -1641,11 +1639,11 @@ relativo questo sarà risolto rispetto alla directory indicata
 da \param{dirfd}. Qualora invece si usi un \itindsub{pathname}{assoluto}
 \textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
 se per \param{dirfd} si usa il valore speciale \const{AT\_FDCWD}, la
 da \param{dirfd}. Qualora invece si usi un \itindsub{pathname}{assoluto}
 \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
-\index{directory~di~lavoro} lavoro corrente del processo. Si tenga presente
-però che questa, come le altre costanti \texttt{AT\_*}, è definita in
-\headfile{fcntl.h}, pertanto se la si vuole usare occorrerà includere comunque
-questo file, anche per le funzioni che non sono definite in esso.
+risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
+processo. Si tenga presente però che questa, come le altre costanti
+\texttt{AT\_*}, è definita in \headfile{fcntl.h}, pertanto se la si vuole
+usare occorrerà includere comunque questo file, anche per le funzioni che non
+sono definite in esso.
 
 Così come il comportamento, anche i valori di ritorno e le condizioni di
 errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
 
 Così come il comportamento, anche i valori di ritorno e le condizioni di
 errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
@@ -2876,12 +2874,11 @@ sez.~\ref{sec:file_stream_thread}).
 Come per i file descriptor anche per gli \textit{stream} è possibile spostarsi
 all'interno di un file per effettuare operazioni di lettura o scrittura in un
 punto prestabilito, sempre che l'operazione di riposizionamento sia supportata
 Come per i file descriptor anche per gli \textit{stream} è possibile spostarsi
 all'interno di un file per effettuare operazioni di lettura o scrittura in un
 punto prestabilito, sempre che l'operazione di riposizionamento sia supportata
-dal file sottostante lo \textit{stream}, nel caso cioè in cui si ha a che
-fare con quello che viene detto un file ad \textsl{accesso casuale}. Dato che
-in un sistema Unix esistono vari tipi di file, come le fifo ed i
-\index{file!di~dispositivo} file di dispositivo (ad esempio i terminali), non
-è scontato che questo sia vero in generale, pur essendolo sempre nel caso di
-file di dati.
+dal file sottostante lo \textit{stream}, nel caso cioè in cui si ha a che fare
+con quello che viene detto un file ad \textsl{accesso casuale}. Dato che in un
+sistema Unix esistono vari tipi di file, come le fifo ed i file di dispositivo
+(ad esempio i terminali), non è scontato che questo sia vero in generale, pur
+essendolo sempre nel caso di file di dati.
 
 Con Linux ed in generale in ogni sistema unix-like la posizione nel file, come
 abbiamo già visto in sez.~\ref{sec:file_lseek}, è espressa da un intero
 
 Con Linux ed in generale in ogni sistema unix-like la posizione nel file, come
 abbiamo già visto in sez.~\ref{sec:file_lseek}, è espressa da un intero