1 \chapter{Files e directories}
2 \label{cha:files_and_dirs}
4 In questo capitolo tratteremo in dettaglio le varie caratteristiche di files e
5 directories, ed in particolare approfondiremo i dettagli su come è organizzata
6 la struttura dei files in un sistema unix; esamineremo poi come è strutturato
7 il sistema base di protezioni e controllo di accesso ai files, e tutta
8 l'interfaccia che permette la manipolazione dei vari attributi di files e
9 directories. Tutto quello che riguarda invece la manipolazione dei contenuti e
10 lasciato ai capitoli successivi.
12 Le funzioni che esamineremo in questo capitolo pertanto sono quelle che
13 permettono di creare e cancellare o leggere le directories, rinominare o
14 cancellare i files ed esaminare o cambiare i loro attributi.
17 \section{L'organizzazione di files e directories}
18 \label{sec:filedir_org}
20 L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
21 medesimi nell'albero descritto brevemente in \ref{sec:fileintr_overview}; una
22 directory comunque, come già specificato in \ref{sec:fileintr_vfs}, è solo un
23 particolare tipo di file che contiene le informazioni che associano un nome al
24 contenuto. Per questo, anche se è usuale parlare di ``file in una directory''
25 in realtà una directory contiene solo dei riferimenti ai file, non i file
28 I nomi contenuti nelle directory sono chiamati componenti (\textit{file name
29 components}), un file può essere indicato rispetto alla directory corrente
30 semplicemente specificando il nome da essa contenuto. Una directory contiene
31 semplicemente un elenco di questi componenti, che possono corrispondere a un
32 qualunque oggetto del filesystem, compresa un'altra directory; l'albero viene
33 appunto creato inserendo directory in altre directory.
35 Il nome di file generico è composto da una serie di \textsl{componenti}
36 separati da una \texttt{/} (in linux più \texttt{/} consecutive sono
37 considerate equivalenti ad una sola). Il nome completo di un file viene
38 usualmente chiamato \textit{pathname}, e anche se il manuale della glibc
39 depreca questo nome (poichè genererebbe confusione, dato che con \textit{path}
40 si indica anche un insieme di directory su cui effettuare una ricerca, come
41 quello in cui si cercano i comandi) l'uso è ormai così comune che è senz'altro
42 più chiaro dell'alternativa proposta.
44 Il processo con cui si associa ad un pathname uno specifico file (cioè si
45 identifica l'inode a cui fare riferimento) è chiamato risoluzione del nome
46 (\textit{file name resolution} o \textit{pathname resolution}).
47 La risoluzione viene fatta esaminando il pathname da destra a sinistra e
48 localizzando ogni componente nella directory indicata dal componente
49 precedente: ovviamente perché il procedimento funzioni occorre che i
50 componenti indicati come directory esistano e siano effettivamente directory,
51 inoltre i permessi devono consentire l'accesso.
53 Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
54 del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
55 seguito, vedi \ref{sec:proc_chroot}) è la stessa per tutti i processi ed
56 equivale alla directory radice dell'albero (come descritto in
57 \ref{sec:fileintr_overview}): in questo caso si parla di un pathname
58 \textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
59 cui torneremo più avanti in \ref{sec:filedir_work_dir}) ed il pathname è detto
62 I componenti \texttt{.} e \texttt{..} hanno un significato speciale e vengono
63 inseriti in ogni directory, il primo fa riferimento alla directory corrente e
64 il secondo alla directory \textsl{genitore} (\textit{parent directory}) cioè
65 la directory che contiene il riferimento alla directory corrente; nel caso
66 questa sia la directory radice allora il riferimento è a se stessa.
69 \section{La manipolazione di files e directories}
70 \label{sec:filedir_handling}
72 Per capire fino in fondo le proprietà di files e directories in un sistema
73 unix ed il funzionamento delle relative funzioni di manipolazione occorre una
74 breve introduzione agli oggetti su cui è basato un filesystem unix; in
75 particolare si riprenderanno, approfondendoli, i concetti di \textit{inode} e
76 \textit{dentry} brevemente introdotti in \ref{sec:fileintr_vfs}.
79 \subsection{Il funzionamento di un filesystem}
80 \label{sec:filedir_filesystem}
82 Come già accennato in \ref{sec:fileintr_overview} linux (ed ogni unix in
83 generale) organizza i dati che tiene su disco attraverso l'uso di un
84 filesystem. Una delle caratteristiche di linux rispetto agli altri unix è
85 quella di poter supportare grazie al VFS una enorme quantità di filesystem
86 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
87 proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
88 daremo una descrizione a grandi linee che si adatta alle caratteristiche
89 comuni di un qualunque filesystem standard unix.
91 Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
92 partizione può contenere un filesystem; quest'ultimo è in genere strutturato
93 secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio aa
94 disposizione per i dati e le directory.
99 \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
100 \label{fig:filedir_disk_filesys}
103 Se si va ad esaminare come è strutturata l'informazione all'interno di un
104 singolo filesystem (tralasciando le parti connesse alla strutturazione e al
105 funzionamento del filesystem stesso come il super-block) avremo una situazione
106 del tipo di quella esposta in \nfig.
110 \caption{Organizzazione di un filesystem}
111 \label{fig:filedir_filesys_detail}
113 da questa figura si evidenzano alcune caratteristiche su cui è bene porre
114 attenzione in quanto sono fondamentali per capire il funzionamento delle
115 funzioni che manipolano i file e le directory su cui torneremo fra poco; in
116 particolare è opportuno ricordare sempre che:
120 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
121 tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
122 fisici che contengono i dati e così via; le informazioni che la funzione
123 \texttt{stat} fornisce provengono dall'\textit{inode}; dentro una directory
124 si troverà solo il nome del file e il numero dell'\textit{inode} ad esso
125 associato, cioè quella che da qui in poi chiameremo una \textit{dentry}.
127 \item Come mostrato in \curfig si possono avere più \textit{dentries} che
128 puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un contatore che
129 contiene il numero di riferimenti (\textit{link count}) che sono stati fatti
130 ad esso, solo quando questo contatore si annulla i dati del file vengono
131 effettivamente rimossi dal disco. Per questo la funzione per cancellare un
132 file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del
133 file, ma si limita a eliminare la \textit{dentry} da una directory e
134 decrementare il numero di riferimenti nell'\textit{inode}.
136 \item Il numero di \textit{inode} nella \textit{dentry} si riferisce ad un
137 \textit{inode} nello stesso filesystem e non ci può essere una directory che
138 contiene riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo
139 limita l'uso del comando \texttt{ln} (che crea una nuova dentry per un file
140 esistente, con la funzione \texttt{link}) al filesystem corrente.
142 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
143 del file non deve essere spostato, viene semplicemente creta una nuova
144 \textit{dentry} per l'\textit{inode} in questione e rimossa la vecchia
145 (questa è la modalità in cui opera normalmente il comando \texttt{mv}
146 attraverso la funzione \texttt{rename}).
150 Infine è bene avere presente che essendo file pure loro, esiste un numero di
151 riferimenti anche per le directories; per cui se ad esempio a partire dalla
152 situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir}
153 nella directory corrente avremo una situazione come quella in \nfig, dove per
154 chiarezza abbiamo aggiunto dei numeri di inode.
156 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
157 è referenziata dalla directory da cui si era partiti (in cui è inserita la
158 nuova dentry che fa riferiemto a \texttt{textdir}) e dalla dentry \texttt{.}
159 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
160 che non contenga a sua volta altre directories. Al contempo la directory da
161 cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
162 adesso sarà referenziata anche dalla dentry \texttt{..} di \texttt{textdir}.
165 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
166 \label{sec:filedir_link}
168 Una delle caratteristiche usate quando si opera con i file è quella di poter
169 creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
170 stesso file accedendovi da directory diverse. Questo è possibile anche in
171 ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
172 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
173 per fare questa operazione.
175 Come si è appena detto l'accesso al contenuto di un file su disco avviene
176 attraverso il suo inode, e il nome che si trova in una directory è solo una
177 etichetta associata ad un puntatore a detto inode. Questo significa che la
178 realizzazione di un link è immediata in quanto uno stesso file può avere tanti
179 nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo
180 stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una
181 particolare preferenza rispetto agli altri.
183 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
184 suole chiamare questo tipo di associazione un collegamento diretto (o
185 \textit{hard link}). Il prototipo della funzione, definita in
186 \texttt{unistd.h} è il seguente:
188 \item \texttt{int link(const char * oldname, const char * newname)}
190 Crea un nuovo collegamento diretto al file indicato da \texttt{oldname}
191 dandogli nome \texttt{newname}.
193 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
194 di errore. La variabile \texttt{errno} viene settata secondo i seguenti
198 \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
200 \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
201 \texttt{newname} non supporta i link diretti.
202 \item \texttt{EACCESS}
203 Non c'è il permesso di scrittura per la directory in cui si vuole creare
205 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
207 \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
208 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
209 \ref{sec:xxx_limits}.
210 \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
211 non può essere ampliata.
212 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
213 su un filesystem montato readonly.
217 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
218 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
219 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
220 richiamato in diverse directory.
222 Per quanto dicevamo in \ref{sec:filedir_filesystem} la creazione del
223 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
224 filesytem; inoltre il filesystem deve supportare i collegamenti diretti (non è
225 il caso ad esempio del filesystem \texttt{vfat} di windows).
227 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
228 ma solo l'amministratore è in grado di creare un collegamento diretto ad
229 un'altra directory, questo lo si fa perché in questo caso è possibile creare
230 dei cerchi nel filesystem (vedi \ref{sec:filedir_symlink}) che molti programmi
231 non sono in grado di gestire e la cui rimozione diventa estremamente
232 complicata (in genere occorre far girare il programma \texttt{fsck} per
233 riparare il filesystem).
236 La rimozione di un file (o più precisamente di una sua dentry) si effettua con
237 la funzione \texttt{unlink}; il suo prototipo, definito in \texttt{unistd.h} è
241 \item \texttt{int unlink(const char * filename)}
243 Cancella il nome specificato dal pathname nella relativa directory e
244 decrementa il numero di riferimenti nel relativo inode.
246 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
247 di errore. La variabile \texttt{errno} viene settata secondo i seguenti
251 \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
253 \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
254 \texttt{newname} non supporta i link diretti.
255 \item \texttt{EACCESS}
256 Non c'è il permesso di scrittura per la directory in cui si vuole creare
258 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
260 \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
261 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
262 \ref{sec:xxx_limits}.
263 \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
264 non può essere ampliata.
265 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
266 su un filesystem montato readonly.
276 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
277 della nnome dalla directory e l'incremento/decremento del numero di
278 riferimenti nell'inode deve essere una operazione atomica (cioè non
279 interrompibile da altri) processi, per questo entrambe queste funzioni sono
280 realizzate tramite una singola system call.
285 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
286 \label{sec:filedir_cre_canc}
289 \subsection{I link simbolici}
290 \label{sec:filedir_sym_link}
292 Siccome tutto ciò funziona facendo riferimento ad un inode, questa funzione
293 può essere applicata soltanto per file che risiedono sullo stesso filesystem,
294 (dato che solo in questo caso è garantita l'unicità dell'inode) e solo per
295 filesystem di tipo unix. Inoltre in linux non è consentito eseguire un link
296 diretto ad una directory.
298 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
299 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
300 come avviene in altri sistemi operativi, dei file che contengono il
301 semplicemente il riferimento ad un altro file (o directory). In questo modo è
302 possibile effettuare link anche attraverso filesystem diversi e a directory, e
303 pure a file che non esistono ancora.
305 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
306 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
307 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
308 lettura del contenuto del medesimo e l'applicazione della funzione al file
309 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
310 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
311 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
312 alle informazioni del link invece che a quelle del file a cui esso fa
315 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
316 dichiarate nell'header file \texttt{unistd.h}.
319 \item \texttt{int symlink(const char * oldname, const char * newname)}
321 Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
322 nome \texttt{newname}.
324 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
325 di errore. La variabile \texttt{errno} viene settata secondo i codici di
326 errore standard di accesso ai files (trattati in dettaglio in
327 \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
330 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
332 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
333 su un filesystem montato readonly.
334 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
335 link è piena e non c'è ulteriore spazio disponibile.
336 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
337 \texttt{oldname} o di \texttt{newname}.
342 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
343 \label{sec:filedir_dir_creat_rem}
345 Per creare una nuova directory si può usare la seguente funzione, omonima
346 dell'analogo comando di shell \texttt{mkdir}; per accedere alla funzioni il
347 programma deve includere il file \texttt{sys/stat.h}.
350 \item \texttt{char * mkdir (const char * dirname, mode\_t mode)}
352 Questa funzione crea una nuova directory vuota con il nome indicato da
353 \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
354 può essere indicato con il pathname assoluto o relativo.
356 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
357 di errore \texttt{errno} viene settata secondo i codici di errore standard
358 di accesso ai files (trattati in dettaglio in
359 \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
361 \item \texttt{EACCESS}
362 Non c'è il permesso di scrittura per la directory in cui si vuole inserire
364 \item \texttt{EEXIST} Un file (o una directory) con quel nome essite di già.
365 \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
366 contiene troppi file. Sotto linux questo normalmente non avviene perchè il
367 filesystem standard consente la creazione di un numero di file maggiore di
368 quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
369 fare anche con filesystem di altri sistemi questo errore può presentarsi.
370 \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
372 \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
373 directory è su un filesystem montato readonly.
378 \subsection{Accesso alle directory}
379 \label{sec:filedir_dir_read}
381 Benchè le directory siano oggetti del filesystem come tutti gli altri non ha
382 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
383 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
384 contengono o ricerche sui medesimi.
386 Per accedere al contenuto delle directory si usano i cosiddetti
387 \textit{directory streams} (chiamati così per l'analogia con i file stream);
388 la funzione \texttt{opendir} apre uno di questi stream e la funzione
389 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
390 \textit{directory entries} (da distinguersi da quelle della cache di cui
391 parlavamo in \ref{sec:fileintr_vfs}) in una opportuna struttura
392 \texttt{struct dirent}.
395 \subsection{La directory di lavoro}
396 \label{sec:filedir_work_dir}
398 A ciascun processo è associato ad una directory nel filesystem che è chiamata
399 directory corrente o directory di lavoro (\textit{current working directory})
400 che è quella a cui si fa riferimento quando un filename è espresso in forma
401 relativa (relativa appunto a questa directory).
403 Quando un utente effettua il login questa directory viene settata alla
404 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
405 della shell consente di cambiarla a piacere, spostandosi da una directory ad
406 un'altra. Siccome la directory corrente resta la stessa quando viene creato
407 un processo figlio, la directory corrente della shell diventa anche la
408 directory corrente di qualunque comando da essa lanciato.
410 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
411 corrente. I prototipi di queste funzioni sono dichiarati in \texttt{unistd.h}.
414 \item \texttt{char * getcwd (char * buffer, size\_t size)}
416 Restituisce il filename completo della directory di lavoro corrente nella
417 stringa puntata da \texttt{buffer}, che deve essere precedentemente
418 allocata, per una dimensione massima di \texttt{size}. Si può anche
419 specificare un puntatore nullo come \textit{buffer}, nel qual caso la
420 stringa sarà allocata automaticamente per una dimensione pari a
421 \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
422 del pathname altrimenti. In questo caso si deve ricordare di disallocara la
423 stringa una volta cessato il suo utilizzo.
425 La funzione restituisce il puntatore \texttt{buffer} se riesce,
426 \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
427 \texttt{errno} è settata con i seguenti codici di errore:
430 \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
432 \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
433 lunghezza del pathname.
434 \item \texttt{EACCES} Manca il permesso di lettura o di ricerca su uno dei
435 componenti del pathname (cioè su una delle directory superiori alla
440 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
441 fatta per compatibilità all'indietro con BSD, che non consente di specificare
442 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
443 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byters, vedi
444 \ref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
445 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
446 contenere il nome del file, e questa è la ragione principale per cui questa
447 funzione è deprecata.
449 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
450 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
451 differenza che essa ritorna il valore della variabile di ambiente
452 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
453 riferimenti simbolici.
455 Come già detto in unix anche le directory sono file, è possibile pertanto
456 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
457 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
458 per cambiare directory di lavoro.
461 \item \texttt{int chdir (const char * pathname)}
463 Come dice il nome (che significa \textit{change directory}) questa funzione
464 serve a cambiare la directory di lavoro a quella speficata dal pathname
465 contenuto nella stringa \texttt{pathname}.
467 \item \texttt{int fchdir (int filedes)} analoga alla precedente, ma usa un
468 file descriptor invece del pathname.
471 Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
472 errore, in caso di errore \texttt{errno} viene settata secondo i codici di
473 errore standard di accesso ai files (trattati in dettaglio in
474 \ref{sec:filedir_access_control}) ai quali si aggiunge il codice
475 \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
486 \section{La manipolazione delle caratteristiche dei files}
487 \label{sec:filedir_infos}
492 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
493 \label{sec:filedir_stat}
495 \subsection{I tipi di file}
496 \label{sec:filedir_file_types}
498 \subsection{La dimensione dei file}
499 \label{sec:filedir_file_size}
501 \subsection{I tempi dei file}
502 \label{sec:filedir_file_times}
504 \subsection{La funzione \texttt{utime}}
505 \label{sec:filedir_utime}
509 \section{Il controllo di accesso ai file}
510 \label{sec:filedir_access_control}
513 \subsection{I flag \texttt{suid} e \texttt{sgid}}
514 \label{sec:filedir_suid_sgid}
516 \subsection{La titolarità di nuovi files e directory}
517 \label{sec:filedir_ownership}
519 \subsection{La funzione \texttt{access}}
520 \label{sec:filedir_access}
522 \subsection{La funzione \texttt{umask}}
523 \label{sec:filedir_umask}
525 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
526 \label{sec:filedir_chmod}
528 \subsection{Il flag \texttt{stiky}}
529 \label{sec:filedir_stiky}
531 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
532 \label{sec:filedir_chown}
536 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
537 %cosiddetto \textit{inode}; questo conterrà informazioni come il
538 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
539 %completo vedi \ntab), i permessi (vedi \ref{sec:file_perms}), le date (vedi
540 %\ref{sec:file_times}).