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 \secref{sec:fileintr_overview};
22 una directory comunque, come già specificato in \secref{sec:fileintr_vfs}, è
23 solo un particolare tipo di file che contiene le informazioni che associano un
24 nome al contenuto. Per questo, anche se è usuale parlare di ``file in una
25 directory'' in realtà una directory contiene solo delle etichette per fare
26 riferimento ai file stessi.
28 I manuale delle librerie del C chiama i nomi contenuti nelle directory
29 \textsl{componenti} (in inglese \textit{file name components}), noi li
30 chiameremo più semplicemente nomi. Un file può essere indicato rispetto alla
31 directory corrente semplicemente specificando il nome da essa contenuto. Una
32 directory contiene semplicemente un elenco di questi nomi, che possono
33 corrispondere a un qualunque oggetto del filesystem, compresa un'altra
34 directory; l'albero viene appunto creato inserendo directory in altre
37 Il nome completo di file generico è composto da una serie di questi
38 \textsl{componenti} separati da una \texttt{/} (in linux più \texttt{/}
39 consecutive sono considerate equivalenti ad una sola). Il nome completo di un
40 file viene usualmente chiamato \textit{pathname}, e anche se il manuale della
41 glibc depreca questo nome (poichè genererebbe confusione, dato che con
42 \textit{path} si indica anche un insieme di directory su cui effettuare una
43 ricerca, come quello in cui si cercano i comandi) l'uso è ormai così comune
44 che è senz'altro più chiaro dell'alternativa proposta.
46 Il processo con cui si associa ad un pathname uno specifico file è chiamato
47 risoluzione del nome (\textit{file name resolution} o \textit{pathname
48 resolution}). La risoluzione viene fatta esaminando il pathname da destra a
49 sinistra e localizzando ogni nome nella directory indicata dal nome
50 precedente: ovviamente perché il procedimento funzioni occorre che i nomi
51 indicati come directory esistano e siano effettivamente directory, inoltre i
52 permessi devono consentire l'accesso.
54 Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
55 del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
56 seguito, vedi \secref{sec:proc_chroot}) è la stessa per tutti i processi ed
57 equivale alla directory radice dell'albero (come descritto in
58 \secref{sec:fileintr_overview}): in questo caso si parla di un pathname
59 \textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
60 cui torneremo più avanti in \secref{sec:filedir_work_dir}) ed il pathname è
61 detto \textsl{relativo}.
63 I nomi \texttt{.} e \texttt{..} hanno un significato speciale e vengono
64 inseriti in ogni directory, il primo fa riferimento alla directory corrente e
65 il secondo alla directory \textsl{genitore} (\textit{parent directory}) cioè
66 la directory che contiene il riferimento alla directory corrente; nel caso
67 questa sia la directory radice allora il riferimento è a se stessa.
70 \section{La manipolazione di files e directories}
71 \label{sec:filedir_handling}
73 Per capire fino in fondo le proprietà di files e directories in un sistema
74 unix ed il funzionamento delle relative funzioni di manipolazione occorre una
75 breve introduzione agli oggetti su cui è basato un filesystem unix; in
76 particolare si riprenderà, approfondendolo sul piano dell'uso nelle funzioni
77 di libreria, il concetto di \textit{inode} di cui abbiamo brevemente accennato
78 le caratteristiche (dal lato dell'implementazione nel kernel) in
79 \secref{sec:fileintr_vfs}.
82 \subsection{Il funzionamento di un filesystem}
83 \label{sec:filedir_filesystem}
85 Come già accennato in \secref{sec:fileintr_overview} linux (ed ogni unix in
86 generale) organizza i dati che tiene su disco attraverso l'uso di un
87 filesystem. Una delle caratteristiche di linux rispetto agli altri unix è
88 quella di poter supportare grazie al VFS una enorme quantità di filesystem
89 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
90 proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
91 daremo una descrizione a grandi linee che si adatta alle caratteristiche
92 comuni di un qualunque filesystem standard unix.
94 Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
95 partizione può contenere un filesystem; quest'ultimo è in genere strutturato
96 secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio a
97 disposizione per i dati e le directory.
102 \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
103 \label{fig:filedir_disk_filesys}
106 Se si va ad esaminare come è strutturata l'informazione all'interno di un
107 singolo filesystem (tralasciando le parti connesse alla strutturazione e al
108 funzionamento del filesystem stesso come il super-block) avremo una situazione
109 del tipo di quella esposta in \nfig.
113 \caption{Organizzazione di un filesystem}
114 \label{fig:filedir_filesys_detail}
116 da questa figura si evidenzano alcune caratteristiche su cui è bene porre
117 attenzione in quanto sono fondamentali per capire il funzionamento delle
118 funzioni che manipolano i file e le directory su cui torneremo fra poco; in
119 particolare è opportuno ricordare sempre che:
123 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
124 tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
125 fisici che contengono i dati e così via; le informazioni che la funzione
126 \texttt{stat} fornisce provengono dall'\textit{inode}; dentro una directory
127 si troverà solo il nome del file e il numero dell'\textit{inode} ad esso
128 associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
129 (traduzione approssimata dell'inglese \textit{directory entry}, che non
130 useremo anche per evitare confusione con le \textit{dentries} del kernel di
131 cui si parlava in \secref{sec:fileintr_vfs}).
133 \item Come mostrato in \curfig si possono avere più voci che puntano allo
134 stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
135 numero di riferimenti (\textit{link count}) che sono stati fatti ad esso,
136 solo quando questo contatore si annulla i dati del file vengono
137 effettivamente rimossi dal disco. Per questo la funzione per cancellare un
138 file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del
139 file, ma si limita a eliminare la relativa voce da una directory e
140 decrementare il numero di riferimenti nell'\textit{inode}.
142 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
143 nello stesso filesystem e non ci può essere una directory che contiene
144 riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
145 l'uso del comando \texttt{ln} (che crea una nuova voce per un file
146 esistente, con la funzione \texttt{link}) al filesystem corrente.
148 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
149 del file non deve essere spostato, viene semplicemente creata una nuova voce
150 per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
151 in cui opera normalmente il comando \texttt{mv} attraverso la funzione
156 Infine è bene avere presente che essendo file pure loro, esiste un numero di
157 riferimenti anche per le directories; per cui se ad esempio a partire dalla
158 situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir}
159 nella directory corrente avremo una situazione come quella in \nfig, dove per
160 chiarezza abbiamo aggiunto dei numeri di inode.
162 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
163 è referenziata dalla directory da cui si era partiti (in cui è inserita la
164 nuova voce che fa riferimento a \texttt{textdir}) e dalla voce \texttt{.}
165 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
166 che non contenga a sua volta altre directories. Al contempo la directory da
167 cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
168 adesso sarà referenziata anche dalla voce \texttt{..} di \texttt{textdir}.
171 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
172 \label{sec:filedir_link}
174 Una delle caratteristiche usate quando si opera con i file è quella di poter
175 creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
176 stesso file accedendovi da directory diverse. Questo è possibile anche in
177 ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
178 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
179 per fare questa operazione.
181 Come si è appena detto l'accesso al contenuto di un file su disco avviene
182 attraverso il suo inode, e il nome che si trova in una directory è solo una
183 etichetta associata ad un puntatore a detto inode. Questo significa che la
184 realizzazione di un link è immediata in quanto uno stesso file può avere tanti
185 nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo
186 stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una
187 particolare preferenza rispetto agli altri.
189 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
190 suole chiamare questo tipo di associazione un collegamento diretto (o
191 \textit{hard link}). Il prototipo della funzione, definita in
192 \texttt{unistd.h}, e le sue caratteritiche principali, come risultano dalla
193 man page, sono le seguenti:
194 \begin{prototype}{int link(const char * oldname, const char * newname)}
195 Crea un nuovo collegamento diretto al file indicato da \texttt{oldname}
196 dandogli nome \texttt{newname}.
198 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
199 di errore. La variabile \texttt{errno} viene settata secondo i seguenti
202 \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
204 \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
205 \texttt{newname} non supporta i link diretti.
206 \item \texttt{EACCESS}
207 Non c'è il permesso di scrittura per la directory in cui si vuole creare
209 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
211 \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
212 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
213 \secref{sec:xxx_limits}.
214 \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
215 non può essere ampliata.
216 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
217 su un filesystem montato readonly.
221 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
222 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
223 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
224 richiamato in diverse directory.
226 Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del
227 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
228 filesytem; inoltre il filesystem deve supportare i collegamenti diretti (non è
229 il caso ad esempio del filesystem \texttt{vfat} di windows).
231 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
232 ma solo l'amministratore è in grado di creare un collegamento diretto ad
233 un'altra directory, questo lo si fa perché in questo caso è possibile creare
234 dei cerchi nel filesystem (vedi \secref{sec:filedir_symlink}) che molti programmi
235 non sono in grado di gestire e la cui rimozione diventa estremamente
236 complicata (in genere occorre far girare il programma \texttt{fsck} per
237 riparare il filesystem).
240 La rimozione di un file (o più precisamente della voce che lo referenzia) si
241 effettua con la funzione \texttt{unlink}; il suo prototipo, definito in
242 \texttt{unistd.h} è il seguente:
244 \begin{prototype}{int unlink(const char * filename)}
245 Cancella il nome specificato dal pathname nella relativa directory e
246 decrementa il numero di riferimenti nel relativo inode.
248 La funzione restituisce zero in caso di successo e -1 per un errore, nel
249 qual caso il file non viene toccato. La variabile \texttt{errno} viene
250 settata secondo i seguenti codici di errore:
252 \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
254 \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
255 \texttt{newname} non supporta i link diretti.
256 \item \texttt{EACCESS}
257 Non c'è il permesso di scrittura per la directory in cui si vuole creare
259 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
261 \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
262 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
263 \secref{sec:xxx_limits}.
264 \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
265 non può essere ampliata.
266 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
267 su un filesystem montato readonly.
271 Per cancellare una voce in una directory è necessario avere il permesso di
272 scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
273 il diritto di esecuzione sulla directory che la contiene (torneremo in
274 dettaglio sui permessi e gli attributi fra poco), se inoltre lo
275 \textit{sticky} bit è settato occorerà anche essere proprietari del file o
276 proprietari della directory (o root, per cui nessuna delle restrizioni è
279 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
280 della nome dalla directory e l'incremento/decremento del numero di
281 riferimenti nell'inode deve essere una operazione atomica (cioè non
282 interrompibile da altri) processi, per questo entrambe queste funzioni sono
283 realizzate tramite una singola system call.
285 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
286 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
287 count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
288 questo però si aggiunge una altra condizione, e cioè che non ci siano processi
289 che abbiano detto file aperto. Come accennato questa proprietà viene spesso
290 usata per essere sicuri di non lasciare file temporanei su disco in caso di
291 crash dei programmi; la tecnica è quella di aprire il file e chiamare
292 \texttt{unlink} subito dopo.
295 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
296 \label{sec:filedir_cre_canc}
299 \subsection{I link simbolici}
300 \label{sec:filedir_sym_link}
302 Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
303 funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
304 in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
305 tipo unix. Inoltre in linux non è consentito eseguire un link diretto ad una
306 directory se non si è root.
308 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
309 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
310 come avviene in altri sistemi operativi, dei file che contengono il
311 semplicemente il riferimento ad un altro file (o directory). In questo modo è
312 possibile effettuare link anche attraverso filesystem diversi e a directory, e
313 pure a file che non esistono ancora.
315 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
316 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
317 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
318 lettura del contenuto del medesimo e l'applicazione della funzione al file
319 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
320 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
321 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
322 alle informazioni del link invece che a quelle del file a cui esso fa
325 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
326 dichiarate nell'header file \texttt{unistd.h}.
328 \begin{prototype}{int symlink(const char * oldname, const char * newname)}
329 Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
330 nome \texttt{newname}.
332 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
333 di errore. La variabile \texttt{errno} viene settata secondo i codici di
334 errore standard di accesso ai files (trattati in dettaglio in
335 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
337 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
339 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
340 su un filesystem montato readonly.
341 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
342 link è piena e non c'è ulteriore spazio disponibile.
343 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
344 \texttt{oldname} o di \texttt{newname}.
349 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
350 \label{sec:filedir_dir_creat_rem}
352 Per creare una nuova directory si può usare la seguente funzione, omonima
353 dell'analogo comando di shell \texttt{mkdir}; per accedere alla funzioni il
354 programma deve includere il file \texttt{sys/stat.h}.
356 \begin{prototype}{char * mkdir (const char * dirname, mode\_t mode)}
357 Questa funzione crea una nuova directory vuota con il nome indicato da
358 \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
359 può essere indicato con il pathname assoluto o relativo.
361 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
362 di errore \texttt{errno} viene settata secondo i codici di errore standard
363 di accesso ai files (trattati in dettaglio in
364 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
366 \item \texttt{EACCESS}
367 Non c'è il permesso di scrittura per la directory in cui si vuole inserire
369 \item \texttt{EEXIST} Un file (o una directory) con quel nome essite di già.
370 \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
371 contiene troppi file. Sotto linux questo normalmente non avviene perchè il
372 filesystem standard consente la creazione di un numero di file maggiore di
373 quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
374 fare anche con filesystem di altri sistemi questo errore può presentarsi.
375 \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
377 \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
378 directory è su un filesystem montato readonly.
383 \subsection{Accesso alle directory}
384 \label{sec:filedir_dir_read}
386 Benchè le directory siano oggetti del filesystem come tutti gli altri non ha
387 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
388 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
389 contengono o ricerche sui medesimi.
391 Per accedere al contenuto delle directory si usano i cosiddetti
392 \textit{directory streams} (chiamati così per l'analogia con i file stream);
393 la funzione \texttt{opendir} apre uno di questi stream e la funzione
394 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
395 \textit{directory entries} (da distinguersi da quelle della cache di cui
396 parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura
397 \texttt{struct dirent}.
400 \subsection{La directory di lavoro}
401 \label{sec:filedir_work_dir}
403 A ciascun processo è associato ad una directory nel filesystem che è chiamata
404 directory corrente o directory di lavoro (\textit{current working directory})
405 che è quella a cui si fa riferimento quando un filename è espresso in forma
406 relativa (relativa appunto a questa directory).
408 Quando un utente effettua il login questa directory viene settata alla
409 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
410 della shell consente di cambiarla a piacere, spostandosi da una directory ad
411 un'altra. Siccome la directory corrente resta la stessa quando viene creato
412 un processo figlio, la directory corrente della shell diventa anche la
413 directory corrente di qualunque comando da essa lanciato.
415 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
416 corrente. I prototipi di queste funzioni sono dichiarati in \texttt{unistd.h}.
418 \begin{prototype}{char * getcwd (char * buffer, size\_t size)}
419 Restituisce il filename completo della directory di lavoro corrente nella
420 stringa puntata da \texttt{buffer}, che deve essere precedentemente
421 allocata, per una dimensione massima di \texttt{size}. Si può anche
422 specificare un puntatore nullo come \textit{buffer}, nel qual caso la
423 stringa sarà allocata automaticamente per una dimensione pari a
424 \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
425 del pathname altrimenti. In questo caso si deve ricordare di disallocara la
426 stringa una volta cessato il suo utilizzo.
428 La funzione restituisce il puntatore \texttt{buffer} se riesce,
429 \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
430 \texttt{errno} è settata con i seguenti codici di errore:
432 \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
434 \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
435 lunghezza del pathname.
436 \item \texttt{EACCES} Manca il permesso di lettura o di ricerca su uno dei
437 componenti del pathname (cioè su una delle directory superiori alla
442 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
443 fatta per compatibilità all'indietro con BSD, che non consente di specificare
444 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
445 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byters, vedi
446 \secref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
447 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
448 contenere il nome del file, e questa è la ragione principale per cui questa
449 funzione è deprecata.
451 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
452 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
453 differenza che essa ritorna il valore della variabile di ambiente
454 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
455 riferimenti simbolici.
457 Come già detto in unix anche le directory sono file, è possibile pertanto
458 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
459 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
460 per cambiare directory di lavoro.
462 \begin{prototype}{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}.
468 \begin{prototype}{int fchdir (int filedes)}
469 Analoga alla precedente, ma usa un 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 \secref{sec:filedir_access_control}) ai quali si aggiunge il codice
475 \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
483 \section{La manipolazione delle caratteristiche dei files}
484 \label{sec:filedir_infos}
489 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
490 \label{sec:filedir_stat}
492 \subsection{I tipi di file}
493 \label{sec:filedir_file_types}
495 \subsection{La dimensione dei file}
496 \label{sec:filedir_file_size}
498 \subsection{I tempi dei file}
499 \label{sec:filedir_file_times}
501 \subsection{La funzione \texttt{utime}}
502 \label{sec:filedir_utime}
506 \section{Il controllo di accesso ai file}
507 \label{sec:filedir_access_control}
510 \subsection{I flag \texttt{suid} e \texttt{sgid}}
511 \label{sec:filedir_suid_sgid}
513 \subsection{La titolarità di nuovi files e directory}
514 \label{sec:filedir_ownership}
516 \subsection{La funzione \texttt{access}}
517 \label{sec:filedir_access}
519 \subsection{La funzione \texttt{umask}}
520 \label{sec:filedir_umask}
522 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
523 \label{sec:filedir_chmod}
525 \subsection{Il flag \texttt{stiky}}
526 \label{sec:filedir_stiky}
528 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
529 \label{sec:filedir_chown}
533 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
534 %cosiddetto \textit{inode}; questo conterrà informazioni come il
535 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
536 %completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
537 %\secref{sec:file_times}).