Piccole correzioni
authorSimone Piccardi <piccardi@gnulinux.it>
Fri, 31 Aug 2018 00:13:12 +0000 (02:13 +0200)
committerSimone Piccardi <piccardi@gnulinux.it>
Fri, 31 Aug 2018 00:13:12 +0000 (02:13 +0200)
filedir.tex

index b077277..622a716 100644 (file)
@@ -3485,16 +3485,19 @@ file e poi si effettua il confronto con i due possibili tipi di file.
 \label{sec:file_file_size}
 
 Abbiamo visto in fig.~\ref{fig:file_stat_struct} che campo \var{st\_size} di
-una struttura \struct{stat} contiene la dimensione del file in byte. Questo
-però è vero solo se si tratta di un file regolare, mentre nel caso di un
-collegamento simbolico la dimensione è quella del \textit{pathname} che il
-collegamento stesso contiene, infine per le \textit{fifo} ed i file di dispositivo
-questo campo è sempre nullo.
-
-Il campo \var{st\_blocks} invece definisce la lunghezza del file in blocchi di
-512 byte. La differenza con \var{st\_size} è che in questo caso si fa
-riferimento alla quantità di spazio disco allocata per il file, e non alla
-dimensione dello stesso che si otterrebbe leggendolo sequenzialmente.
+una struttura \struct{stat} contiene la dimensione del file in byte. In realtà
+questo è vero solo se si tratta di un file regolare contenente dei dati; nel
+caso di un collegamento simbolico invece la dimensione è quella del
+\textit{pathname} che il collegamento stesso contiene, e per una directory
+quella dello spazio occupato per le voci della stessa (che dipende da come
+queste vengono mantenute dal filesystem), infine per le \textit{fifo}, i socket
+ed i file di dispositivo questo campo è sempre nullo.
+
+Il campo \var{st\_blocks} invece definisce la lunghezza del file espressa in
+numero di blocchi di 512 byte. La differenza con \var{st\_size} è che in
+questo caso si fa riferimento alla quantità di spazio disco allocata per il
+file, e non alla dimensione dello stesso che si otterrebbe leggendolo
+sequenzialmente.
 
 Si deve tener presente infatti che la lunghezza del file riportata in
 \var{st\_size} non è detto che corrisponda all'occupazione dello spazio su
@@ -3520,9 +3523,9 @@ troncamento, scartando i dati presenti al di là della dimensione scelta come
 nuova fine del file.
 
 Un file può sempre essere troncato a zero aprendolo con il flag
-\const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
-dimensione si possono usare le due funzioni di sistema \funcd{truncate} e
-\funcd{ftruncate}, i cui prototipi sono:
+\const{O\_TRUNC} (vedi sez.~\ref{sec:file_open_close}), ma questo è un caso
+particolare; per qualunque altra dimensione si possono usare le due funzioni
+di sistema \funcd{truncate} e \funcd{ftruncate}, i cui prototipi sono:
 
 \begin{funcproto}{
 \fhead{unistd.h}
@@ -3632,7 +3635,8 @@ sui tre tempi. Il comando \cmd{ls} (quando usato con le opzioni \cmd{-l} o
 \cmd{-t}) mostra i tempi dei file secondo lo schema riportato nell'ultima
 colonna di tab.~\ref{tab:file_file_times}. Si noti anche come non esista, a
 differenza di altri sistemi operativi, un \textsl{tempo di creazione} di un
-file.
+file, anche se vari filesystem lo supportano e dal kernel 4.11 è ottenibile
+con la funzione \func{statx} (vedi sez.~\ref{sec:file_openat}).
 
 L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
 difetto progettuale di Unix, questo infatti comporta la necessità di
@@ -3642,23 +3646,22 @@ accesso in lettura sui dati bufferizzati. Questo comporta un ovvio costo sia
 in termini di prestazioni, che di consumo di risorse come la batteria per i
 portatili, o i cicli di riscrittura per i dischi su memorie riscrivibili.
 
-
 Per questo motivo abbiamo visto in sez.~\ref{sec:filesystem_mounting} come
-nello sviluppo del kernel siano stati introdotti degli opportuni \textit{mount
-  flag} che consentissero di evitare di aggiornare continuamente una
-informazione che nella maggior parte dei casi non interessa. Per questo i
-valori che si possono trovare per l'\textit{access time} dipendono dalle
-opzioni di montaggio, ed anche, essendo stato cambiato il comportamento di
-default a partire dalla versione 2.6.30, dal kernel che si sta usando. 
+nello sviluppo del siano stati introdotti degli opportuni \textit{mount flag}
+che consentono di evitare di aggiornare continuamente una informazione che
+nella maggior parte dei casi non interessa. Per questo i valori
+dell'\textit{access time} possono dipendere dalle opzioni di montaggio, ed
+anche, essendo stato cambiato il comportamento di default a partire dalla
+versione 2.6.30, dal kernel che si sta usando.
 
 In generale quello che si ha con i kernel più recenti è che il tempo di ultimo
 accesso viene aggiornato solo se è precedente al tempo di ultima modifica o
 cambiamento, o se è passato più di un giorno dall'ultimo accesso. Così si può
 rendere evidente che vi è stato un accesso dopo una modifica e che il file
-viene comunque osservato regolarmente, conservando tutte le informazioni
-veramente utili senza dover consumare risorse in scritture continue per
-mantenere costantemente aggiornata una informazione che a questo punto non ha
-più nessuna rilevanza pratica.\footnote{qualora ce ne fosse la necessità è
+viene comunque osservato regolarmente, conservando le informazioni veramente
+utili senza consumare risorse in scritture continue per mantenere
+costantemente aggiornata una informazione che a questo punto non ha più
+nessuna rilevanza pratica.\footnote{qualora ce ne fosse la necessità è
   comunque possibile, tramite l'opzione di montaggio \texttt{strictatime},
   richiedere in ogni caso il comportamento tradizionale.}
 
@@ -3839,8 +3842,8 @@ realizzare.\footnote{esistono comunque molti programmi che consentono di farlo
 
 A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
 tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
-nanosecondi per la gran parte dei filesystem. Lulteriore informazione può
-essere acceduta attraverso altri campi appositamente aggiunti alla struttura
+nanosecondi per la gran parte dei filesystem. L'ulteriore informazione può
+essere ottenuta attraverso altri campi appositamente aggiunti alla struttura
 \struct{stat}. Se si sono definite le macro \macro{\_BSD\_SOURCE} o
 \macro{\_SVID\_SOURCE} questi sono \var{st\_atim.tv\_nsec},
 \var{st\_mtim.tv\_nsec} e \var{st\_ctim.tv\_nsec} se queste non sono definite,