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 delle etichette per fare riferimento ai
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 \ref{sec:proc_chroot}) è la stessa per tutti i processi ed
57 equivale alla directory radice dell'albero (come descritto in
58 \ref{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 \ref{sec:filedir_work_dir}) ed il pathname è detto
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 \ref{sec:fileintr_vfs}.
82 \subsection{Il funzionamento di un filesystem}
83 \label{sec:filedir_filesystem}
85 Come già accennato in \ref{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 \ref{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
150 \textit{dentry} per l'\textit{inode} in questione e rimossa la vecchia
151 (questa è la modalità in cui opera normalmente il comando \texttt{mv}
152 attraverso la funzione \texttt{rename}).
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:
195 \item \texttt{int link(const char * oldname, const char * newname)}
197 Crea un nuovo collegamento diretto al file indicato da \texttt{oldname}
198 dandogli nome \texttt{newname}.
200 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
201 di errore. La variabile \texttt{errno} viene settata secondo i seguenti
205 \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
207 \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
208 \texttt{newname} non supporta i link diretti.
209 \item \texttt{EACCESS}
210 Non c'è il permesso di scrittura per la directory in cui si vuole creare
212 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
214 \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
215 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
216 \ref{sec:xxx_limits}.
217 \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
218 non può essere ampliata.
219 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
220 su un filesystem montato readonly.
224 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
225 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
226 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
227 richiamato in diverse directory.
229 Per quanto dicevamo in \ref{sec:filedir_filesystem} la creazione del
230 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
231 filesytem; inoltre il filesystem deve supportare i collegamenti diretti (non è
232 il caso ad esempio del filesystem \texttt{vfat} di windows).
234 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
235 ma solo l'amministratore è in grado di creare un collegamento diretto ad
236 un'altra directory, questo lo si fa perché in questo caso è possibile creare
237 dei cerchi nel filesystem (vedi \ref{sec:filedir_symlink}) che molti programmi
238 non sono in grado di gestire e la cui rimozione diventa estremamente
239 complicata (in genere occorre far girare il programma \texttt{fsck} per
240 riparare il filesystem).
243 La rimozione di un file (o più precisamente di una sua dentry) si effettua con
244 la funzione \texttt{unlink}; il suo prototipo, definito in \texttt{unistd.h} è
248 \item \texttt{int unlink(const char * filename)}
250 Cancella il nome specificato dal pathname nella relativa directory e
251 decrementa il numero di riferimenti nel relativo inode.
253 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
254 di errore. La variabile \texttt{errno} viene settata secondo i seguenti
258 \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
260 \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
261 \texttt{newname} non supporta i link diretti.
262 \item \texttt{EACCESS}
263 Non c'è il permesso di scrittura per la directory in cui si vuole creare
265 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
267 \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
268 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
269 \ref{sec:xxx_limits}.
270 \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
271 non può essere ampliata.
272 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
273 su un filesystem montato readonly.
283 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
284 della nnome dalla directory e l'incremento/decremento del numero di
285 riferimenti nell'inode deve essere una operazione atomica (cioè non
286 interrompibile da altri) processi, per questo entrambe queste funzioni sono
287 realizzate tramite una singola system call.
292 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
293 \label{sec:filedir_cre_canc}
296 \subsection{I link simbolici}
297 \label{sec:filedir_sym_link}
299 Siccome tutto ciò funziona facendo riferimento ad un inode, questa funzione
300 può essere applicata soltanto per file che risiedono sullo stesso filesystem,
301 (dato che solo in questo caso è garantita l'unicità dell'inode) e solo per
302 filesystem di tipo unix. Inoltre in linux non è consentito eseguire un link
303 diretto ad una directory.
305 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
306 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
307 come avviene in altri sistemi operativi, dei file che contengono il
308 semplicemente il riferimento ad un altro file (o directory). In questo modo è
309 possibile effettuare link anche attraverso filesystem diversi e a directory, e
310 pure a file che non esistono ancora.
312 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
313 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
314 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
315 lettura del contenuto del medesimo e l'applicazione della funzione al file
316 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
317 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
318 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
319 alle informazioni del link invece che a quelle del file a cui esso fa
322 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
323 dichiarate nell'header file \texttt{unistd.h}.
326 \item \texttt{int symlink(const char * oldname, const char * newname)}
328 Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
329 nome \texttt{newname}.
331 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
332 di errore. La variabile \texttt{errno} viene settata secondo i codici di
333 errore standard di accesso ai files (trattati in dettaglio in
334 \ref{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}.
357 \item \texttt{char * mkdir (const char * dirname, mode\_t mode)}
359 Questa funzione crea una nuova directory vuota con il nome indicato da
360 \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
361 può essere indicato con il pathname assoluto o relativo.
363 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
364 di errore \texttt{errno} viene settata secondo i codici di errore standard
365 di accesso ai files (trattati in dettaglio in
366 \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
368 \item \texttt{EACCESS}
369 Non c'è il permesso di scrittura per la directory in cui si vuole inserire
371 \item \texttt{EEXIST} Un file (o una directory) con quel nome essite di già.
372 \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
373 contiene troppi file. Sotto linux questo normalmente non avviene perchè il
374 filesystem standard consente la creazione di un numero di file maggiore di
375 quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
376 fare anche con filesystem di altri sistemi questo errore può presentarsi.
377 \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
379 \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
380 directory è su un filesystem montato readonly.
385 \subsection{Accesso alle directory}
386 \label{sec:filedir_dir_read}
388 Benchè le directory siano oggetti del filesystem come tutti gli altri non ha
389 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
390 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
391 contengono o ricerche sui medesimi.
393 Per accedere al contenuto delle directory si usano i cosiddetti
394 \textit{directory streams} (chiamati così per l'analogia con i file stream);
395 la funzione \texttt{opendir} apre uno di questi stream e la funzione
396 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
397 \textit{directory entries} (da distinguersi da quelle della cache di cui
398 parlavamo in \ref{sec:fileintr_vfs}) in una opportuna struttura
399 \texttt{struct dirent}.
402 \subsection{La directory di lavoro}
403 \label{sec:filedir_work_dir}
405 A ciascun processo è associato ad una directory nel filesystem che è chiamata
406 directory corrente o directory di lavoro (\textit{current working directory})
407 che è quella a cui si fa riferimento quando un filename è espresso in forma
408 relativa (relativa appunto a questa directory).
410 Quando un utente effettua il login questa directory viene settata alla
411 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
412 della shell consente di cambiarla a piacere, spostandosi da una directory ad
413 un'altra. Siccome la directory corrente resta la stessa quando viene creato
414 un processo figlio, la directory corrente della shell diventa anche la
415 directory corrente di qualunque comando da essa lanciato.
417 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
418 corrente. I prototipi di queste funzioni sono dichiarati in \texttt{unistd.h}.
421 \item \texttt{char * getcwd (char * buffer, size\_t size)}
423 Restituisce il filename completo della directory di lavoro corrente nella
424 stringa puntata da \texttt{buffer}, che deve essere precedentemente
425 allocata, per una dimensione massima di \texttt{size}. Si può anche
426 specificare un puntatore nullo come \textit{buffer}, nel qual caso la
427 stringa sarà allocata automaticamente per una dimensione pari a
428 \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
429 del pathname altrimenti. In questo caso si deve ricordare di disallocara la
430 stringa una volta cessato il suo utilizzo.
432 La funzione restituisce il puntatore \texttt{buffer} se riesce,
433 \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
434 \texttt{errno} è settata con i seguenti codici di errore:
437 \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
439 \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
440 lunghezza del pathname.
441 \item \texttt{EACCES} Manca il permesso di lettura o di ricerca su uno dei
442 componenti del pathname (cioè su una delle directory superiori alla
447 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
448 fatta per compatibilità all'indietro con BSD, che non consente di specificare
449 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
450 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byters, vedi
451 \ref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
452 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
453 contenere il nome del file, e questa è la ragione principale per cui questa
454 funzione è deprecata.
456 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
457 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
458 differenza che essa ritorna il valore della variabile di ambiente
459 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
460 riferimenti simbolici.
462 Come già detto in unix anche le directory sono file, è possibile pertanto
463 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
464 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
465 per cambiare directory di lavoro.
468 \item \texttt{int chdir (const char * pathname)}
470 Come dice il nome (che significa \textit{change directory}) questa funzione
471 serve a cambiare la directory di lavoro a quella speficata dal pathname
472 contenuto nella stringa \texttt{pathname}.
474 \item \texttt{int fchdir (int filedes)} analoga alla precedente, ma usa un
475 file descriptor invece del pathname.
478 Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
479 errore, in caso di errore \texttt{errno} viene settata secondo i codici di
480 errore standard di accesso ai files (trattati in dettaglio in
481 \ref{sec:filedir_access_control}) ai quali si aggiunge il codice
482 \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
493 \section{La manipolazione delle caratteristiche dei files}
494 \label{sec:filedir_infos}
499 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
500 \label{sec:filedir_stat}
502 \subsection{I tipi di file}
503 \label{sec:filedir_file_types}
505 \subsection{La dimensione dei file}
506 \label{sec:filedir_file_size}
508 \subsection{I tempi dei file}
509 \label{sec:filedir_file_times}
511 \subsection{La funzione \texttt{utime}}
512 \label{sec:filedir_utime}
516 \section{Il controllo di accesso ai file}
517 \label{sec:filedir_access_control}
520 \subsection{I flag \texttt{suid} e \texttt{sgid}}
521 \label{sec:filedir_suid_sgid}
523 \subsection{La titolarità di nuovi files e directory}
524 \label{sec:filedir_ownership}
526 \subsection{La funzione \texttt{access}}
527 \label{sec:filedir_access}
529 \subsection{La funzione \texttt{umask}}
530 \label{sec:filedir_umask}
532 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
533 \label{sec:filedir_chmod}
535 \subsection{Il flag \texttt{stiky}}
536 \label{sec:filedir_stiky}
538 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
539 \label{sec:filedir_chown}
543 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
544 %cosiddetto \textit{inode}; questo conterrà informazioni come il
545 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
546 %completo vedi \ntab), i permessi (vedi \ref{sec:file_perms}), le date (vedi
547 %\ref{sec:file_times}).