1 \chapter{Files e directories}
2 \label{cha:files_and_dirs}
4 In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
5 file e directory, ed in particolare esamineremo come è strutturato il sistema
6 base di protezioni e controllo di accesso ai file, e tutta l'interfaccia che
7 permette la manipolazione dei vari attributi di file e directory. Tutto quello
8 che riguarda invece la manipolazione del contenuto dei file è lasciato ai
13 \section{Il controllo di accesso ai file}
14 \label{sec:filedir_access_control}
16 Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
17 del controllo di accesso ai file, che viene implementato per qualunque
18 filesystem standard. In questa sezione ne esamineremo i concetti essenziali e
19 le funzioni usate per gestirne i vari aspetti.
22 \subsection{I permessi per l'accesso ai file}
23 \label{sec:filedir_perm_overview}
25 Il controllo di accesso ai file in unix segue un modello abbastanza semplice,
26 ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre
27 livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
28 tipo unix, e non è detto che sia applicabile a un filesystem
29 qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
30 per il quale vengono assegnati in maniera fissa con un opzione in fase di
31 montaggio}. Esistono inoltre estensioni che permettono di implementare le
32 ACL (\textit{Access Control List}) che sono un meccanismo di controllo di
33 accesso molto più sofisticato.
35 Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
36 \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
37 identificatoti di utenti e gruppi (uid e gig) già accennato in
38 \secref{sec:intro_multiuser}, e un insieme di permessi che sono divisi in tre
39 classi, e cioè attribuiti rispettivamente al proprietario, a qualunque utente
40 faccia parte del gruppo cui appartiene il file, e a tutti gli altri utenti.
42 I permessi sono espressi da un insieme di 12 bit: di questi i nove meno
43 significativi sono usati a gruppi di tre per indicare i permessi base di
44 lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere
45 \textit{w}, \textit{r} \textit{x} nell'output di \cmd{ls}) applicabili
46 rispettivamente al proprietario, al gruppo, a tutti (una descrizione più
47 dettagliata dei vari permessi associati ai file è riportata in
48 \secref{sec:filedir_suid_sgid}). I restanti tre bit sono usati per indicare
49 alcune caratteristiche più complesse (\textit{suid}, \textit{sgid}, e
50 \textit{sticky}) su cui pure torneremo in seguito (vedi
51 \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}).
53 Tutte queste informazioni sono tenute per ciascun file nell'inode, in
54 opportuni bit del campo \var{st\_mode} della struttura letta da \func{stat}
55 (vedi \figref{fig:filedir_stat_struct}) che possono essere controllati con i
56 valori riportati in \ntab.
61 \begin{tabular}[c]{|c|l|}
63 \var{st\_mode} bit & Significato \\
66 \macro{S\_IRUSR} & \textit{user-read}, l'utente può leggere \\
67 \macro{S\_IWUSR} & \textit{user-write}, l'utente può scrivere \\
68 \macro{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire \\
70 \macro{S\_IRGRP} & \textit{group-read}, il gruppo può leggere \\
71 \macro{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere \\
72 \macro{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire\\
74 \macro{S\_IROTH} & \textit{other-read}, tutti possono leggere \\
75 \macro{S\_IWOTH} & \textit{other-write}, tutti possono scrivere \\
76 \macro{S\_IXOTH} & \textit{other-execute}, tutti possono eseguire\\
78 \caption{I bit dei permessi di accesso ai file, come definiti in
79 \texttt{<sys/stat.h>}}
80 \label{tab:file_bit_perm}
84 % Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
85 % confrontandoli con quelli del file e se l'operazione richiesta è compatibile
86 % con i permessi associati al file essa viene eseguita, altrimenti viene
87 % bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
88 % viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale
90 % pertanto accesso senza restrizione a qualunque file del sistema.
92 % In realtà il procedimento è più complesso di quanto descritto in maniera
93 % elementare qui; inoltre ad un processo sono associati diversi identificatori,
94 % torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}.
99 \subsection{I flag \texttt{suid} e \texttt{sgid}}
100 \label{sec:filedir_suid_sgid}
102 \subsection{La titolarità di nuovi files e directory}
103 \label{sec:filedir_ownership}
106 \subsection{La funzione \texttt{access}}
107 \label{sec:filedir_access}
110 \subsection{La funzione \texttt{umask}}
111 \label{sec:filedir_umask}
114 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
115 \label{sec:filedir_chmod}
117 \subsection{Il flag \texttt{sticky}}
118 \label{sec:filedir_sticky}
120 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
121 \label{sec:filedir_chown}
126 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
127 %cosiddetto \textit{inode}; questo conterrà informazioni come il
128 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
129 %completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
130 %\secref{sec:file_times}).
135 \section{La manipolazione di file e directory}
137 Le prime funzioni che considereremo sono quelle relative alla gestione di file
138 e directory, secondo le caratteristiche standard che essi presentano in un
139 filesystem unix, la cui struttura abbiamo esaminato in precedenza (vedi
140 \secref{sec:fileintr_filesystem}).
142 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
143 \label{sec:fileintr_link}
145 Una delle caratteristiche usate quando si opera con i file è quella di poter
146 creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
147 stesso file accedendovi da directory diverse. Questo è possibile anche in
148 ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
149 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
150 per fare questa operazione.
152 Come spiegato in \secref{sec:fileintr_architecture} l'accesso al contenuto di
153 un file su disco avviene attraverso il suo inode, e il nome che si trova in
154 una directory è solo una etichetta associata ad un puntatore a detto inode.
155 Questo significa che la realizzazione di un link è immediata in quanto uno
156 stesso file può avere tanti nomi diversi allo stesso tempo, dati da
157 altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
158 questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
160 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
161 suole chiamare questo tipo di associazione un collegamento diretto (o
162 \textit{hard link}). Il prototipo della funzione e le sue caratteristiche
163 principali, come risultano dalla man page, sono le seguenti:
164 \begin{prototype}{unistd.h}
165 {int link(const char * oldpath, const char * newpath)}
166 Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath}
167 dandogli nome \texttt{newpath}.
169 La funzione restituisce zero in caso di successo e -1 in caso di errore. La
170 variabile \texttt{errno} viene settata opportunamente, i principali codici
173 \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
175 \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e
176 \texttt{newpath} non supporta i link diretti o è una directory.
177 \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di
179 \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il
180 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
181 \secref{sec:xxx_limits}).
186 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
187 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
188 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
189 richiamato in diverse directory.
191 Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del
192 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
193 filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
194 il caso ad esempio del filesystem \texttt{vfat} di windows).
196 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
197 in alcuni filesystem solo l'amministratore è in grado di creare un
198 collegamento diretto ad un'altra directory, questo lo si fa perché in questo
199 caso è possibile creare dei circoli nel filesystem (vedi
200 \secref{sec:fileintr_symlink}) che molti programmi non sono in grado di
201 gestire e la cui rimozione diventa estremamente complicata (in genere occorre
202 far girare il programma \texttt{fsck} per riparare il filesystem); data la sua
203 pericolosità in generale nei filesystem usati in Linux questa caratteristica è
204 stata disabilitata, e la funzione restituisce l'errore \texttt{EPERM}.
206 La rimozione di un file (o più precisamente della voce che lo referenzia) si
207 effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
209 \begin{prototype}{unistd.h}{int unlink(const char * pathname)}
210 Cancella il nome specificato dal pathname nella relativa directory e
211 decrementa il numero di riferimenti nel relativo inode. Nel caso di link
212 simbolico cancella il link simbolico; nel caso di socket, fifo o file di
213 dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
214 uno di questi oggetti possono continuare ad utilizzarlo.
216 La funzione restituisce zero in caso di successo e -1 per un errore, nel
217 qual caso il file non viene toccato. La variabile \texttt{errno} viene
218 settata secondo i seguenti codici di errore:
220 \item \texttt{EISDIR} \var{pathname} si riferisce ad una directory
221 (valore specifico ritornato da linux che non consente l'uso di
222 \texttt{unlink} con le directory, e non conforme allo standard POSIX, che
223 prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia
224 consnetita o il processo non abbia privilegi sufficienti).
225 \item \texttt{EROFS} \var{pathname} è su un filesystem montato in sola
227 \item \texttt{EISDIR} \var{pathname} fa riferimento a una directory.
231 Per cancellare una voce in una directory è necessario avere il permesso di
232 scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
233 il diritto di esecuzione sulla directory che la contiene (torneremo in
234 dettaglio sui permessi e gli attributi fra poco), se inoltre lo
235 \textit{sticky} bit è settato occorrerà anche essere proprietari del file o
236 proprietari della directory (o root, per cui nessuna delle restrizioni è
239 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
240 della nome dalla directory e l'incremento/decremento del numero di riferimenti
241 nell'inode deve essere una operazione atomica (cioè non interrompibile da
242 altri) processi, per questo entrambe queste funzioni sono realizzate tramite
243 una singola system call.
245 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
246 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
247 count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
248 questo però si aggiunge una altra condizione, e cioè che non ci siano processi
249 che abbiano detto file aperto. Come accennato questa proprietà viene spesso
250 usata per essere sicuri di non lasciare file temporanei su disco in caso di
251 crash dei programmi; la tecnica è quella di aprire il file e chiamare
252 \texttt{unlink} subito dopo.
254 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
255 \label{sec:fileintr_remove}
257 Al contrario di quanto avviene con altri unix in Linux non è possibile usare
258 \texttt{unlink} sulle directory, per cancellare una directory si può usare la
259 funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
260 funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
261 per cancellare un file o una directory (e funziona anche per i sistemi che non
262 supportano i link diretti), che per i file è identica alla \texttt{unlink} e
263 per le directory è identica alla \texttt{rmdir}:
265 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
266 Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e
267 \texttt{rmdir} per le directory.
269 La funzione restituisce zero in caso di successo e -1 per un errore, nel
270 qual caso il file non viene toccato. Per i codici di errori vedi quanto
271 riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}.
274 Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il
275 vantaggio nell'uso di questa funzione al posto della chiamata successiva di
276 \texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in
277 questo modo non c'è la possibilità che un processo che cerchi di accedere al
278 nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante.
280 \begin{prototype}{stdio.h}
281 {int rename(const char *oldpath, const char *newpath)}
282 Rinomina un file, spostandolo fra directory diverse quando richiesto.
284 La funzione restituisce zero in caso di successo e -1 per un errore, nel
285 qual caso il file non viene toccato. La variabile \texttt{errno} viene
286 settata secondo i seguenti codici di errore:
288 \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre
289 \texttt{oldpath} non è una directory.
290 \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
292 \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e
294 \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da
295 parte di qualche processo (come directory di lavoro o come root) o del
296 sistema (come mount point).
297 \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di
298 \texttt{oldpath} o più in generale si è cercato di creare una directory
299 come sottodirectory di se stessa.
300 \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link
301 consentiti o è una directory e la directory che contiene \texttt{newpath}
302 ha già il massimo numero di link.
303 \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory
304 o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una
306 \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello
307 spazio di indirizzi del processo.
308 \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
309 cui si vuole creare il nuovo link o una delle directory del pathname non
310 consente la ricerca (permesso di esecuzione).
311 \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o
312 \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non
313 consentono rispettivamente la cancellazione e la creazione del file, o il
314 filesystem non supporta i link.
315 \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo.
316 \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
318 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
319 completare l'operazione.
320 \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura.
321 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
323 \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la
328 \subsection{I link simbolici}
329 \label{sec:fileintr_symlink}
331 Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
332 funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
333 in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
334 tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una
337 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
338 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
339 come avviene in altri sistemi operativi, dei file che contengono il
340 semplicemente il riferimento ad un altro file (o directory). In questo modo è
341 possibile effettuare link anche attraverso filesystem diversi e a directory, e
342 pure a file che non esistono ancora.
344 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
345 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
346 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
347 lettura del contenuto del medesimo e l'applicazione della funzione al file
348 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
349 o rinominare i file operano direttamente sul link simbolico (per l'elenco vedi
350 \ntab). Inoltre esistono funzioni apposite, come la \texttt{readlink} e la
351 \texttt{lstat} per accedere alle informazioni del link invece che a quelle del
352 file a cui esso fa riferimento.
354 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
355 dichiarate nell'header file \texttt{unistd.h}.
357 \begin{prototype}{unistd.h}
358 {int symlink(const char * oldname, const char * newname)}
359 Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
360 nome \texttt{newname}.
362 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
363 di errore. La variabile \texttt{errno} viene settata secondo i codici di
364 errore standard di accesso ai files (trattati in dettaglio in
365 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
367 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
369 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
370 su un filesystem montato readonly.
371 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
372 link è piena e non c'è ulteriore spazio disponibile.
373 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
374 \texttt{oldname} o di \texttt{newname}.
378 Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare
379 un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
380 questa funzione è la:
382 \begin{prototype}{unistd.h}
383 {int readlink(const char * path, char * buff, size\_t size)}
384 Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer
385 \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
386 carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
387 piccolo per contenerla.
389 La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
390 -1 per un errore, in caso di errore. La variabile \texttt{errno} viene
391 settata secondo i codici di errore:
393 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
395 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
396 su un filesystem montato readonly.
397 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
398 link è piena e non c'è ulteriore spazio disponibile.
399 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
400 \texttt{oldname} o di \texttt{newname}.
404 In \ntab\ si è riportato un elenco dei comportamenti delle varie funzioni che
405 operano sui file rispetto ai link simbolici; specificando quali seguono il
406 link simbolico e quali possono operare direttamente sul suo contenuto.
410 \begin{tabular}[c]{|l|c|c|}
412 Funzione & Segue il link & Non segue il link \\
415 \func{access} & $\bullet$ & \\
416 \func{chdir} & $\bullet$ & \\
417 \func{chmod} & $\bullet$ & \\
418 \func{chown} & & $\bullet$ \\
419 \func{creat} & $\bullet$ & \\
420 \func{exec} & $\bullet$ & \\
421 \func{lchown} & $\bullet$ & $\bullet$ \\
423 \func{lstat} & & $\bullet$ \\
424 \func{mkdir} & $\bullet$ & \\
425 \func{mkfifo} & $\bullet$ & \\
426 \func{mknod} & $\bullet$ & \\
427 \func{open} & $\bullet$ & \\
428 \func{opendir} & $\bullet$ & \\
429 \func{pathconf} & $\bullet$ & \\
430 \func{readlink} & & $\bullet$ \\
431 \func{remove} & & $\bullet$ \\
432 \func{rename} & & $\bullet$ \\
433 \func{stat} & $\bullet$ & \\
434 \func{truncate} & $\bullet$ & \\
435 \func{unlink} & & $\bullet$ \\
438 \caption{Uso dei link simbolici da parte di alcune funzioni.}
439 \label{tab:filedir_symb_effect}
441 si noti che non si è specificato il comportamento delle funzioni che operano
442 con i file descriptor, in quanto la gestione del link simbolico viene in
443 genere effttuata dalla funzione che restituisce il file descriptor
444 (normalmente la \func{open}).
448 \includegraphics[width=5cm]{img/link_loop.eps}
449 \caption{Esempio di loop nel filesystem creato con un link simbolico.}
450 \label{fig:filedir_link_loop}
453 Un caso comune che si può avere con i link simbolici è la creazione dei
454 cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta
455 la struttura della directory \file{/boot}. Come si vede si è creato al suo
456 interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
457 tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
458 bootloader estremamente avanzato in grado di accedere direttamente
459 attraverso vari filesystem al file da lanciare come sistema operativo) di
460 vedere i file in questa directory, che è montata su una partizione separata
461 (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
462 visti dal sistema operativo.}.
464 Questo può causare problemi per tutti quei programmi che effettuassero uno
465 scan di una directory senza tener conto dei link simbolici, in quel caso
466 infatti il loop nella directory
468 Un secondo punto da tenere presente è che un link simbolico può essere fatto
469 anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
470 nella nostra directory con un link del tipo:
472 $ln -s /tmp/tmp_file temporaneo
474 ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura
475 \file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola
476 lettura (ad esempio con \cmd{cat}) otterremmo:
479 cat: prova: No such file or directory
481 con un errore che sembra sbagliato, dato \cmd{ls} ci mostrerebbe l'esistenza
482 di \file{temporaneo}.
485 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
486 \label{sec:filedir_dir_creat_rem}
488 Per creare una nuova directory si può usare la seguente funzione, omonima
489 dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati
490 programma deve includere il file \texttt{sys/types.h}.
492 \begin{prototype}{sys/stat.h}
493 {int mkdir (const char * dirname, mode\_t mode)}
494 Questa funzione crea una nuova directory vuota con il nome indicato da
495 \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
496 può essere indicato con il pathname assoluto o relativo.
498 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
499 di errore \texttt{errno} viene settata secondo i codici di errore standard
500 di accesso ai files (trattati in dettaglio in
501 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
503 \item \texttt{EACCESS}
504 Non c'è il permesso di scrittura per la directory in cui si vuole inserire
506 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già.
507 \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
508 contiene troppi file. Sotto Linux questo normalmente non avviene perché il
509 filesystem standard consente la creazione di un numero di file maggiore di
510 quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
511 fare anche con filesystem di altri sistemi questo errore può presentarsi.
512 \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
514 \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
515 directory è su un filesystem montato readonly.
520 \subsection{Accesso alle directory}
521 \label{sec:filedir_dir_read}
523 Benché le directory siano oggetti del filesystem come tutti gli altri non ha
524 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
525 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
526 contengono o ricerche sui medesimi.
528 Per accedere al contenuto delle directory si usano i cosiddetti
529 \textit{directory streams} (chiamati così per l'analogia con i file stream);
530 la funzione \texttt{opendir} apre uno di questi stream e la funzione
531 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
532 \textit{directory entries} (da distinguersi da quelle della cache di cui
533 parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura
534 \texttt{struct dirent}.
537 \subsection{La directory di lavoro}
538 \label{sec:filedir_work_dir}
540 A ciascun processo è associato ad una directory nel filesystem che è chiamata
541 directory corrente o directory di lavoro (\textit{current working directory})
542 che è quella a cui si fa riferimento quando un filename è espresso in forma
543 relativa (relativa appunto a questa directory).
545 Quando un utente effettua il login questa directory viene settata alla
546 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
547 della shell consente di cambiarla a piacere, spostandosi da una directory ad
548 un'altra. Siccome la directory corrente resta la stessa quando viene creato
549 un processo figlio, la directory corrente della shell diventa anche la
550 directory corrente di qualunque comando da essa lanciato.
552 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
555 \begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
556 Restituisce il filename completo della directory di lavoro corrente nella
557 stringa puntata da \texttt{buffer}, che deve essere precedentemente
558 allocata, per una dimensione massima di \texttt{size}. Si può anche
559 specificare un puntatore nullo come \textit{buffer}, nel qual caso la
560 stringa sarà allocata automaticamente per una dimensione pari a
561 \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
562 del pathname altrimenti. In questo caso si deve ricordare di disallocare la
563 stringa una volta cessato il suo utilizzo.
565 La funzione restituisce il puntatore \texttt{buffer} se riesce,
566 \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
567 \texttt{errno} è settata con i seguenti codici di errore:
569 \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
571 \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
572 lunghezza del pathname.
573 \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei
574 componenti del pathname (cioè su una delle directory superiori alla
579 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
580 fatta per compatibilità all'indietro con BSD, che non consente di specificare
581 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
582 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
583 \secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
584 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
585 contenere il nome del file, e questa è la ragione principale per cui questa
586 funzione è deprecata.
588 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
589 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
590 differenza che essa ritorna il valore della variabile di ambiente
591 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
592 riferimenti simbolici.
594 Come già detto in unix anche le directory sono file, è possibile pertanto
595 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
596 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
597 per cambiare directory di lavoro.
599 \begin{prototype}{unistd.h}{int chdir (const char * pathname)}
600 Come dice il nome (che significa \textit{change directory}) questa funzione
601 serve a cambiare la directory di lavoro a quella specificata dal pathname
602 contenuto nella stringa \texttt{pathname}.
605 \begin{prototype}{unistd.h}{int fchdir (int filedes)}
606 Analoga alla precedente, ma usa un file descriptor invece del pathname.
608 Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
609 errore, in caso di errore \texttt{errno} viene settata secondo i codici di
610 errore standard di accesso ai files (trattati in dettaglio in
611 \secref{sec:filedir_access_control}) ai quali si aggiunge il codice
612 \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
618 \section{La manipolazione delle caratteristiche dei files}
619 \label{sec:filedir_infos}
621 Come spiegato in \secref{sec:fileintr_filesystem} tutte le informazioni
622 generali relative alle caratteristiche di ciascun file sono mantenute
623 nell'inode. Vedremo in questa sezione come sia possibile accedervi usando la
624 funzione \texttt{stat} ed esamineremo alcune funzioni utilizzabili per
625 manipolare una parte di questa informazione. Tutto quello che invece riguarda
626 il meccanismo di controllo di accesso ad i file e le relative funzioni di
627 manipolazione sarà invece esaminanto in \secref{sec:filedir_access_control}.
630 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
631 \label{sec:filedir_stat}
633 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
634 delle funzioni \func{stat}, che è la funzione che il comando \cmd{ls} usa
635 per poter stampare tutti i dati dei files. I prototipi di queste funzioni sono
638 \headdecl{sys/types.h}
639 \headdecl{sys/stat.h}
642 \funcdecl{int stat(const char *file\_name, struct stat *buf)} Legge le
643 informazione del file specificato da \var{file\_name} e le inserisce in
646 \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
647 \func{stat} eccetto che se il \var{file\_name} è un link simbolico vengono
648 lette le informazioni relativa ad esso e non al file a cui fa riferimento.
650 \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
651 eccetto che si usa con un file aperto, specificato tramite il suo file
652 descriptor \var{filedes}.
654 Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
655 caso di errore \texttt{errno} viene settato ai valori:
657 \item \texttt{EACCESS} non c'è il permesso di accedere al file.
658 \item \texttt{ENOTDIR} una componente del pathname non è una directory.
659 \item \texttt{EMLOOP} ci sono troppi link simbolici nel pathname.
660 \item \texttt{EFAULT} i puntatori usati sono fuori dallo spazio di indirizzi
662 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
663 completare l'operazione.
664 \item \texttt{ENAMETOOLONG} il filename è troppo lungo.
668 La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in
669 generale dipende dall'implementazione, la versione usata da Linux è mostrata
670 in \nfig, così come riportata dalla man page (in realtà la definizione
671 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
672 riservati per estensioni come tempi più precisi, o per il padding dei campi).
677 \begin{minipage}[c]{15cm}
678 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
680 dev_t st_dev; /* device */
681 ino_t st_ino; /* inode */
682 mode_t st_mode; /* protection */
683 nlink_t st_nlink; /* number of hard links */
684 uid_t st_uid; /* user ID of owner */
685 gid_t st_gid; /* group ID of owner */
686 dev_t st_rdev; /* device type (if inode device) */
687 off_t st_size; /* total size, in bytes */
688 unsigned long st_blksize; /* blocksize for filesystem I/O */
689 unsigned long st_blocks; /* number of blocks allocated */
690 time_t st_atime; /* time of last access */
691 time_t st_mtime; /* time of last modification */
692 time_t st_ctime; /* time of last change */
697 \caption{La struttura \texttt{stat} per la lettura delle informazioni dei
699 \label{fig:filedir_stat_struct}
702 Si noti come i vari membri della struttura siano specificati come tipi nativi
703 del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
704 \texttt{sys/types.h}).
707 \subsection{I tipi di file}
708 \label{sec:filedir_file_types}
710 Come riportato in \tabref{tab:fileintr_file_types} in Linux oltre ai file e
711 alle directory esistono vari altri oggetti che possono stare su un filesystem;
712 il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode}.
714 Dato che il valore numerico può variare a seconda delle implementazioni lo
715 standard POSIX definisce un insieme di macro per verificare il tipo di files,
716 queste venfono usate anche da Linux che supporta pure le estensioni per link
717 simbolici e socket definite da BDS, l'elenco è riportato in \ntab:
721 \begin{tabular}[c]{|l|l|}
723 Macro & Tipo del file \\
726 \macro{S\_ISREG(m)} & file normale \\
727 \macro{S\_ISDIR(m)} & directory \\
728 \macro{S\_ISCHR(m)} & device a caraetteri \\
729 \macro{S\_ISBLK(m)} & device a blocchi\\
730 \macro{S\_ISFIFO(m)} & fifo \\
731 \macro{S\_ISLNK(m)} & link simbolico \\
732 \macro{S\_ISSOCK(m)} & socket \\
735 \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h})}
736 \label{tab:filedir_file_type_macro}
739 Oltre a queste macro è possibile usare direttamente il valore di
740 \var{st\_mode} per ricavare il significato dei vari bit in esso memorizzati,
741 per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in
746 \begin{tabular}[c]{|l|c|l|}
748 Flag & Valore & Significato \\
751 \macro{S\_IFMT} & 0170000 & bitmask for the file type bitfields \\
752 \macro{S\_IFSOCK} & 0140000 & socket \\
753 \macro{S\_IFLNK} & 0120000 & symbolic link \\
754 \macro{S\_IFREG} & 0100000 & regular file \\
755 \macro{S\_IFBLK} & 0060000 & block device \\
756 \macro{S\_IFDIR} & 0040000 & directory \\
757 \macro{S\_IFCHR} & 0020000 & character device \\
758 \macro{S\_IFIFO} & 0010000 & fifo \\
759 \macro{S\_ISUID} & 0004000 & set UID bit \\
760 \macro{S\_ISGID} & 0002000 & set GID bit (see below) \\
761 \macro{S\_ISVTX} & 0001000 & sticky bit (see below) \\
762 \macro{S\_IRWXU} & 00700 & mask for file owner permissions \\
763 \macro{S\_IRUSR} & 00400 & owner has read permission \\
764 \macro{S\_IWUSR} & 00200 & owner has write permission \\
765 \macro{S\_IXUSR} & 00100 & owner has execute permission \\
766 \macro{S\_IRWXG} & 00070 & mask for group permissions \\
767 \macro{S\_IRGRP} & 00040 & group has read permission \\
768 \macro{S\_IWGRP} & 00020 & group has write permission \\
769 \macro{S\_IXGRP} & 00010 & group has execute permission \\
770 \macro{S\_IRWXO} & 00007 & mask for permissions for others (not in
772 \macro{S\_IROTH} & 00004 & others have read permission \\
773 \macro{S\_IWOTH} & 00002 & others have write permisson \\
774 \macro{S\_IXOTH} & 00001 & others have execute permission \\
777 \caption{Flag per il campo \var{st\_mode} (definite in
778 \texttt{sys/stat.h})}
779 \label{tab:filedir_file_mode_flags}
782 Il primo valore definisce la maschera dei bit usati nei quali viene
783 memorizzato il tipo di files, mentre gli altri possono essere usati per
784 effettuare delle selezioni sul tipo di file voluto, combinando opportunamente
785 i vari flag; ad esempio se si volesse controllare se un file è una directory o
786 un file ordinario si potrebbe definire la condizione:
787 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
788 #define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG))
790 in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
791 poi si effettua il confronto con la combinazione di tipi scelta.
793 \subsection{La dimensione dei file}
794 \label{sec:filedir_file_size}
796 Il membro \var{st\_size} contiene la dimensione del file in bytes (se il file
797 è un file normale, nel caso di un link simbolico al dimensione è quella del
798 pathname che contiene).
800 Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
801 bytes. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
802 i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
803 per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
804 dimensione inferiore sarebbe inefficiente.
806 Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
807 che corrisponda all'occupazione dello spazio su disco per via della possibile
808 esistenza dei cosiddetti \textsl{buchi} (detti normalmente \textit{holes}) che
809 si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
810 una \func{seek} (vedi \secref{sec:fileunix_lseek}) oltre la sua conclusione
813 In tal caso si avranno differenti risultati a seconda del modi in cui si
814 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
815 numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
816 legge dal file (ad esempio usando \cmd{wc -c}), dato che in tal caso per le
817 parti non scritte vengono restituiti degli zeri, si avrà lo stesso risultato
820 Se è sempre possibile allargare un file scrivendoci sopra od usando la
821 funzione \func{seek} per spostarsi oltre la sua fine. Esistono però anche casi
822 in cui si può avere bisogno di effettuare un troncamento scartando i dati al
823 di là della dimensione scelta come nuova fine del file.
825 Un file può essere troncato a zero aprendolo con il flag \macro{O\_TRUNC}, ma
826 questo è un caso particolare; per qualunque altra dimensione si possono usare
829 \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
830 length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad
831 un valore massimo specificato da \var{lenght}.
833 \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate}
834 eccetto che si usa con un file aperto, specificato tramite il suo file
837 Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
838 caso di errore \texttt{errno} viene settato ai valori:
840 \item \texttt{EACCESS} non c'è il permesso di accedere al file.
841 \item \texttt{ENOTDIR} una componente del pathname non è una directory.
842 \item \texttt{EMLOOP} ci sono troppi link simbolici nel pathname.
843 \item \texttt{EFAULT} i puntatori usati sono fuori dallo spazio di indirizzi
845 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
846 completare l'operazione.
847 \item \texttt{ENOENT} il file non esiste.
848 \item \texttt{ENAMETOOLONG} il filename è troppo lungo.
852 Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
853 perduti; il comportamento in caso di lunghezza inferiore non è specificato e
854 dipende dall'implementazione: il file può essere lasciato invariato o esteso
855 fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con
856 zeri (e in genere si ha la creazione di un hole nel file).
859 \subsection{I tempi dei file}
860 \label{sec:filedir_file_times}
862 Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
863 nell'inode insieme agli altri attibuti del file e possono essere letti tramite
864 la funzione \func{stat}, che li restituisce attraverso tre campi della
865 struttura in \figref{fig:filedir_stat_struct}. Il significato di detti tempi e
866 dei relativi campi è riportato nello schema in \ntab:
870 \begin{tabular}[c]{|c|l|l|c|}
872 Membro & Significato & Funzione&opzione \\
875 \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\
876 \var{st\_mtime}& ultima modifica ai dati del file &\func{write}& default\\
877 \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod},
878 \func{utime} & \cmd{-c} \\
881 \caption{I tre tempi associati a ciascun file}
882 \label{tab:filedir_file_times}
885 Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
886 modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di
887 cambiamento di stato (il \textit{chage time} \var{st\_ctime}). Il primo
888 infatti fa riferimento ad una modifica del contenuto di un file, mentre il
889 secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la
890 funzione \func{link} e molte altre che vedremo in seguito) che modificano solo
891 le informazioni contenute nell'inode senza toccare il file, diventa necessario
892 l'utilizzo di un altro tempo.
894 Il sistema non tiene conto dell'ultimo accesso all'inode, pertanto funzioni
895 come \func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il
896 tempo di ultimo accesso viene di solito usato per cancellare i file che non
897 servono più dopo un certo lasso di tempo (ad esempio \cmd{leafnode} cancella i
898 vecchi articoli sulla base di questo tempo).
900 Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere
901 quali file necessitano di essere ricompilati o (talvolta insieme anche al
902 tempo di cambiamento di stato) per decidere quali file devono essere
903 archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni
904 \cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato
905 nell'ultima colonna di \curtab.
907 L'effetto delle varie funzioni di manipolazione dei file sui tempi è
908 illustrato in \ntab. Si sono riportati gli effetti sia per il file a cui si fa
909 riferimento, sia per la directory che lo contiene; questi ultimi possono
910 essere capiti se si tiene conto di quanto già detto, e cioè che anche le
911 directory sono files, che il sistema tratta in maniera del tutto analoga agli
914 Per questo motivo tutte le volte che compiremo una operazione su un file che
915 comporta una modifica della sua directory entry, andremo anche a scrivere
916 sulla directory che lo contiene cambiandone il tempo di modifica. Un esempio
917 di questo può essere la cancellazione di un file, mentre leggere o scrivere o
918 cambiarne i permessi ha effetti solo sui tempi del file.
923 \begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
925 \multicolumn{1}{|c|}{Funzione}
926 &\multicolumn{3}{p{2cm}}{File o directory di riferimento}
927 &\multicolumn{3}{p{2cm}}{Directory genitrice del riferimento}
928 &\multicolumn{1}{|c|}{Note} \\
930 & \textsl{(a)} & \textsl{(m)}& \textsl{(c)}
931 & \textsl{(a)} & \textsl{(m)}& \textsl{(c)}& \\
934 \func{chmod}, \func{fchmod}
935 & & &$\bullet$& & & & \\
936 \func{chown}, \func{fchown}
937 & & &$\bullet$& & & & \\
939 &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& con
940 \macro{O\_CREATE} \\ \func{creat}
941 & &$\bullet$&$\bullet$& &$\bullet$&$\bullet$&
942 con \macro{O\_TRUNC} \\ \func{exec}
943 &$\bullet$& & & & & & \\
945 & & &$\bullet$& & & & \\
947 & & &$\bullet$& &$\bullet$&$\bullet$& \\
949 &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& \\
951 &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& \\
953 &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& con
954 \macro{O\_CREATE} \\ \func{open}
955 & &$\bullet$&$\bullet$& & & & con
956 \macro{O\_TRUNC} \\ \func{pipe}
957 &$\bullet$&$\bullet$&$\bullet$& & & & \\
959 &$\bullet$& & & & & & \\
961 & & &$\bullet$& &$\bullet$&$\bullet$& using
962 \func{unlink}\\ \func{remove}
963 & & & & &$\bullet$&$\bullet$& using
964 \func{rmdir}\\ \func{rename}
965 & & &$\bullet$& &$\bullet$&$\bullet$& per entrambi
966 gli argomenti\\ \func{rmdir}
967 & & & & &$\bullet$&$\bullet$& \\
968 \func{truncate}, \func{ftruncate}
969 & &$\bullet$&$\bullet$& & & & \\
971 & & &$\bullet$& &$\bullet$&$\bullet$& \\
973 &$\bullet$&$\bullet$&$\bullet$& & & & \\
975 & &$\bullet$&$\bullet$& & & & \\
978 \caption{Effetti delle varie funzioni su tempi di ultimo accesso
979 \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento
981 \label{tab:filedir_times_effects}
984 Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
985 creazione del file, usato da molti altri sistemi operativi, che in unix non
989 \subsection{La funzione \texttt{utime}}
990 \label{sec:filedir_utime}
992 I tempi di ultimo accesso e modifica possono essere cambiati usando la
993 funzione \func{utime}, il cui prototipo è:
995 \begin{prototype}{utime.h}
996 {int utime(const char * filename, struct utimbuf *times)}
998 Cambia i tempi di ultimo accesso e modifica dell'inode specificato da
999 \var{filename} secondo i campi \var{actime} e \var{modtime} di \var{times}. Se
1000 questa è \macro{NULL} allora viene usato il tempo corrente.
1002 La funzione restituisce zero in caso di successo e -1 in caso di errore, nel
1003 qual caso \var{errno} è settata opportunamente.
1005 \item \texttt{EACCESS} non si ha il permesso di scrittura sul file.
1006 \item \texttt{ENOENT} \var{filename} non esiste.
1010 La struttura \var{utimebuf} usata da \func{utime} è definita come:
1011 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
1013 time_t actime; /* access time */
1014 time_t modtime; /* modification time */
1018 L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
1019 cosa è l'argomento \var{times}; se è \textit{NULL} la funzione setta il tempo
1020 corrente ed è sufficiente avere accesso in scrittura al file; se invece si è
1021 specificato un valore la funzione avrà successo solo se si è proprietari del
1022 file (o si hanno i privilegi di amministratore).
1024 Si tenga presente che non è comunque possibile specificare il tempo di
1025 cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
1026 volte che si modifica l'inode (quindi anche alla chiamata di \func{utime}).
1027 Questo serve anche come misura di sicurezza per evitare che si possa
1028 modificare un file nascondendo completamente le proprie tracce. In realtà la
1029 cosa resta possibile, se si è in grado di accedere al device, scrivendo
1030 direttamente sul disco senza passare attraverso il filesystem, ma ovviamente è
1031 molto più complicato da realizzare.