Indicizzazioni varie
[gapil.git] / fileunix.tex
index 1bae4dd1a392cb4148cb7e9b20698647c13b8d53..bfaab858ad4566a48af8e5c4240b5eb3b2a17356 100644 (file)
@@ -304,7 +304,8 @@ descriptor con il valore pi
                          a 31 bit. \\
     \hline
     \hline  % modalità di operazione coi file
                          a 31 bit. \\
     \hline
     \hline  % modalità di operazione coi file
-    \const{O\_APPEND}  & Il file viene aperto in append mode. Prima di ciascuna
+    \const{O\_APPEND}  & Il file viene aperto in \itindex{append~mode}
+                         \textit{append mode}. Prima di ciascuna 
                          scrittura la posizione corrente viene sempre impostata
                          alla fine del file. Con NFS si può avere una
                          corruzione del file se più di un processo scrive allo
                          scrittura la posizione corrente viene sempre impostata
                          alla fine del file. Con NFS si può avere una
                          corruzione del file se più di un processo scrive allo
@@ -355,9 +356,10 @@ descriptor con il valore pi
   \label{tab:file_open_flags}
 \end{table}
 
   \label{tab:file_open_flags}
 \end{table}
 
-\footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
-  il kernel deve simularla, ma questo comporta la possibilità di una race
-  condition, vedi sez.~\ref{sec:file_atomic}.}
+\footnotetext[4]{il problema è che NFS non supporta la scrittura in
+  \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma
+  questo comporta la possibilità di una \itindex{race~condition} \textit{race
+    condition}, vedi sez.~\ref{sec:file_atomic}.}
 
 \footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
   una \func{read} con un valore nullo e non con un errore, questo introduce
 
 \footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
   una \func{read} con un valore nullo e non con un errore, questo introduce
@@ -493,9 +495,10 @@ positivo come numero di byte dall'inizio del file. Tutte le operazioni di
 lettura e scrittura avvengono a partire da questa posizione che viene
 automaticamente spostata in avanti del numero di byte letti o scritti.
 
 lettura e scrittura avvengono a partire da questa posizione che viene
 automaticamente spostata in avanti del numero di byte letti o scritti.
 
-In genere (a meno di non avere richiesto la modalità \const{O\_APPEND}) questa
-posizione viene impostata a zero all'apertura del file. È possibile impostarla
-ad un valore qualsiasi con la funzione \funcd{lseek}, il cui prototipo è:
+In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
+\const{O\_APPEND}) questa posizione viene impostata a zero all'apertura del
+file. È possibile impostarla ad un valore qualsiasi con la funzione
+\funcd{lseek}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{unistd.h}
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{unistd.h}
@@ -708,11 +711,11 @@ scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo 
 Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
 a partire dalla posizione corrente nel file e sposta automaticamente la
 posizione in avanti del numero di byte scritti. Se il file è aperto in
 Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
 a partire dalla posizione corrente nel file e sposta automaticamente la
 posizione in avanti del numero di byte scritti. Se il file è aperto in
-modalità \const{O\_APPEND} i dati vengono sempre scritti alla fine del file.
-Lo standard POSIX richiede che i dati scritti siano immediatamente disponibili
-ad una \func{read} chiamata dopo che la \func{write} che li ha scritti è
-ritornata; ma dati i meccanismi di caching non è detto che tutti i filesystem
-supportino questa capacità.
+modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
+alla fine del file.  Lo standard POSIX richiede che i dati scritti siano
+immediatamente disponibili ad una \func{read} chiamata dopo che la
+\func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
+non è detto che tutti i filesystem supportino questa capacità.
 
 Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
 Per i file ordinari il numero di byte scritti è sempre uguale a quello
 
 Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
 Per i file ordinari il numero di byte scritti è sempre uguale a quello
@@ -781,10 +784,11 @@ stesso file, in particolare occorre tenere presente che:
   scrittura eccede la dimensione corrente del file questo verrà esteso
   automaticamente con l'aggiornamento del campo \var{i\_size}
   nell'inode\index{inode}.
   scrittura eccede la dimensione corrente del file questo verrà esteso
   automaticamente con l'aggiornamento del campo \var{i\_size}
   nell'inode\index{inode}.
-\item se un file è in modalità \const{O\_APPEND} tutte le volte che viene
-  effettuata una scrittura la posizione corrente viene prima impostata alla
-  dimensione corrente del file letta dall'inode\index{inode}. Dopo la
-  scrittura il file viene automaticamente esteso.
+\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
+  le volte che viene effettuata una scrittura la posizione corrente viene
+  prima impostata alla dimensione corrente del file letta
+  dall'inode\index{inode}. Dopo la scrittura il file viene automaticamente
+  esteso.
 \item l'effetto di \func{lseek} è solo quello di cambiare il campo
   \var{f\_pos} nella struttura \struct{file} della \textit{file table}, non
   c'è nessuna operazione sul file su disco. Quando la si usa per porsi alla
 \item l'effetto di \func{lseek} è solo quello di cambiare il campo
   \var{f\_pos} nella struttura \struct{file} della \textit{file table}, non
   c'è nessuna operazione sul file su disco. Quando la si usa per porsi alla
@@ -855,11 +859,12 @@ ma il nostro primo processo avr
 
 Il problema è che usare due system call in successione non è un'operazione
 atomica; il problema è stato risolto introducendo la modalità
 
 Il problema è che usare due system call in successione non è un'operazione
 atomica; il problema è stato risolto introducendo la modalità
-\const{O\_APPEND}. In questo caso infatti, come abbiamo descritto in
-precedenza, è il kernel che aggiorna automaticamente la posizione alla fine
-del file prima di effettuare la scrittura, e poi estende il file. Tutto questo
-avviene all'interno di una singola system call (la \func{write}) che non
-essendo interrompibile da un altro processo costituisce un'operazione atomica.
+\itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
+descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
+alla fine del file prima di effettuare la scrittura, e poi estende il file.
+Tutto questo avviene all'interno di una singola system call (la \func{write})
+che non essendo interrompibile da un altro processo costituisce un'operazione
+atomica.
 
 Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
 creare un \textsl{file di lock}\index{file!di lock}, bloccandosi se il file
 
 Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
 creare un \textsl{file di lock}\index{file!di lock}, bloccandosi se il file