Altri indici, aggiornamenti date di copyright e dizionari locali.
[gapil.git] / fileunix.tex
index 1bae4dd1a392cb4148cb7e9b20698647c13b8d53..ae9e15e0cf2888ed43631db6ebbf576d0fd4a680 100644 (file)
@@ -1,6 +1,6 @@
 %% fileunix.tex
 %%
-%% Copyright (C) 2000-2005 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2006 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
@@ -81,7 +81,7 @@ file, fra cui:
 \item lo stato del file (nel campo \var{f\_flags}).
 \item il valore della posizione corrente (l'\textit{offset}) nel file (nel
   campo \var{f\_pos}).
-\item un puntatore all'inode\index{inode}\footnote{nel kernel 2.4.x si è in
+\item un puntatore \index{inode} all'inode\footnote{nel kernel 2.4.x si è in
     realtà passati ad un puntatore ad una struttura \struct{dentry} che punta a
     sua volta all'inode\index{inode} passando per la nuova struttura del VFS.}
   del file.
@@ -118,10 +118,10 @@ stato chiuso nessuno in precedenza).
 
 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
 processo viene lanciato dalla shell con almeno tre file aperti. Questi, per
-quanto appena detto, avranno come \textit{file
-  descriptor}\index{file!descriptor} i valori 0, 1 e 2.  Benché questa sia
-soltanto una convenzione, essa è seguita dalla gran parte delle applicazioni,
-e non aderirvi potrebbe portare a gravi problemi di interoperabilità.
+quanto appena detto, avranno come \index{file!descriptor} \textit{file
+  descriptor} i valori 0, 1 e 2.  Benché questa sia soltanto una convenzione,
+essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe
+portare a gravi problemi di interoperabilità.
 
 Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
 il file da cui il processo si aspetta di ricevere i dati in ingresso. Il
@@ -296,6 +296,7 @@ descriptor con il valore pi
                          \itindex{Denial~of~Service~(DoS)}
                          \textit{DoS}\protect\footnotemark\ quando 
                          \func{opendir} viene chiamata su una fifo o su un
+                         dispositivo associato ad una unità a nastri, non deve
                          dispositivo a nastri; non deve essere utilizzato
                          al di fuori dell'implementazione di \func{opendir}. \\
     \const{O\_LARGEFILE}&nel caso di sistemi a 32 bit che supportano file di
@@ -304,7 +305,8 @@ descriptor con il valore pi
                          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
@@ -355,9 +357,10 @@ descriptor con il valore pi
   \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
@@ -493,9 +496,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.
 
-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}
@@ -708,11 +712,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
-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
@@ -781,10 +785,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}.
-\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
@@ -838,8 +843,8 @@ Se dal punto di vista della lettura dei dati questo non comporta nessun
 problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
 maniera imprevedibile.  Il sistema però fornisce in alcuni casi la possibilità
 di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
-utilizzare meccanismi di sincronizzazione più complessi (come il \textit{file
-  locking} \index{file!locking}, che esamineremo in
+utilizzare meccanismi di sincronizzazione più complessi (come il
+\index{file!locking} \textit{file locking}, che esamineremo in
 sez.~\ref{sec:file_locking}).
 
 Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
@@ -855,11 +860,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à
-\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
@@ -1051,7 +1057,7 @@ descriptor, che non riguardano la normale lettura e scrittura di dati, ma la
 gestione sia delle loro proprietà, che di tutta una serie di ulteriori
 funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
   gestiscono con questa funzione varie modalità di I/O asincrono (vedi
-  sez.~\ref{sec:file_asyncronous_operation}) e il file locking
+  sez.~\ref{sec:file_asyncronous_operation}) e il \textit{file locking}
   \index{file!locking} (vedi sez.~\ref{sec:file_locking}).}
 
 Per queste operazioni di manipolazione e di controllo delle varie proprietà e
@@ -1330,4 +1336,4 @@ relativi ad operazioni comunque eseguibili anche attraverso \func{fcntl}.
 % LocalWords:  SETOWN GETSIG SETSIG sigaction SIGINFO siginfo SETLEASE lease is
 % LocalWords:  truncate GETLEASE NOTIFY all'I AND ACCMODE ioctl everything argp
 % LocalWords:  framebuffer request ENOTTY CDROM nell'header magic number
-% LocalWords:  FIOCLEX FIONCLEX FIOASYNC FIONBIO
+% LocalWords:  FIOCLEX FIONCLEX FIOASYNC FIONBIO NOATIME