\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
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}
\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
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.}
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. La ulteriore 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,
projects / gapil.git / commitdiff