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 del
104 filesystem (tralasciando le parti che non riguardano direttamente la gestione
105 di file e directory come il super-block) avremo una situazione del tipo di
106 quella esposta in \nfig.
111 \caption{Organizzazione di un filesystem}
112 \label{fig:filedir_filesys_detail}
116 Quanto mostrato in \curfig\ mette in evidenza alcune caratteristiche di un
117 filesystem unix su cui è bene porre attenzione in quanto sono fondamentali per
118 capire il funzionamento delle funzioni che manipolano i file e le directory su
119 cui torneremo fra poco; in 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'inode; dentro una directory si
127 troverà solo il nome del file e il numero dell'inode ad esso associato, cioè
130 \item Come mostrato in \curfig si possono avere più dentries che puntano allo
131 stesso inode. Ogni inode ha un contatore che contiene il numero di
132 riferimenti (\textit{link count}) che sono stati fatti ad esso, solo quando
133 questo contatore si annulla il file può essere cancellato. Per questo in
134 generale non esiste una funzione che cancelli un file, ma solo la funzione
135 \texttt{unlink} che si chiama così proprio perché che toglie un riferimento
136 da una directory (cancellando la dentry), il che non comporta
137 automaticamente pure la eliminazione dei blocchi sul disco.
139 \item Siccome il numero di inode nella dentry si riferisce ad un inode nello
140 stesso filesystem non ci può essere una directory che contiene riferimenti
141 ad inodes relativi ad altri filesystem, questo limita l'uso del comando
142 \texttt{ln} (che crea una nuova dentry per un file esistente, con la
143 funzione \texttt{link}) al filesystem corrente.
145 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
146 del file non deve essere spostato, ma basta creare una nuova dentry per
147 l'inode in questione rimuovendo la vecchia (che è la modalità in cui opera
148 normalmente il comando \texttt{mv} attraveso la funzione \texttt{rename}).
152 Infine è bene avere presente che esiste un numero di riferimenti anche per le
153 directories, se a partire dalla situazione mostrata in \curfig\ creiamo una
154 nuova directory \texttt{textdir} avremo una situazione come quella in \nfig,
155 dove per chiarezza abbiamo aggiunto dei numeri di inode.
157 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
158 è referenziata dalla directory da cui si era partiti (in cui è inserita la
159 nuova dentry che fa riferiemto a \texttt{textdir}) e dalla dentry \texttt{.}
160 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
161 che non contenga a sua volta altre directories. Al contempo la directory da
162 cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
163 adesso sarà referenziata anche dalla dentry \texttt{..} di \texttt{textdir}.
166 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
167 \label{sec:filedir_link}
169 Una delle caratteristiche usate quando si opera con i file è quella di poter
170 creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
171 stesso file accedendovi da directory diverse. Questo è possibile anche in
172 ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
173 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
174 per fare questa operazione.
176 Come si è appena visto l'accesso al contenuto di un file su disco avviene
177 attraverso il suo \textit{inode}, e il nome che si trova in una directory è
178 solo una etichetta associata ad un puntatore a detto inode. Questo significa
179 che la realizzazione di un link è immediata in quanto uno stesso file può
180 avere tanti nomi diversi allo stesso tempo, dati da altrettante diverse
181 associazioni allo stesso inode; si noti poi che nessuno di questi nomi viene
182 ad assumere una particolare preferenza rispetto agli altri.
184 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
185 suole chiamare questo tipo di associazione un collegamento diretto (o
186 \textit{hard link}). La creazione di un nuovo link diretto non copia il
187 contenuto del file, ma si limita ad aumentare di uno il numero di referenze al
188 file aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
189 essere così richiamato in diverse directory.
192 \item \texttt{int link(const char * oldname, const char * newname)}
194 Crea un nuovo link diretto al file indicato da \texttt{oldname} dandogli
195 nome \texttt{newname}.
197 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
198 di errore. La variabile \texttt{errno} viene settata secondo i codici di
199 errore standard di accesso ai files (trattati in dettaglio in
200 \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
203 \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
205 \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
206 \texttt{newname} non supporta i link diretti.
207 \item \texttt{EACCESS}
208 Non c'è il permesso di scrittura per la directory in cui si vuole creare
210 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
212 \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
213 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
214 \ref{sec:xxx_limits}.
215 \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
216 non può essere ampliata.
217 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
218 su un filesystem montato readonly.
224 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
225 \label{sec:filedir_cre_canc}
228 \subsection{I link simbolici}
229 \label{sec:filedir_sym_link}
231 Siccome tutto ciò funziona facendo riferimento ad un inode, questa funzione
232 può essere applicata soltanto per file che risiedono sullo stesso filesystem,
233 (dato che solo in questo caso è garantita l'unicità dell'inode) e solo per
234 filesystem di tipo unix. Inoltre in linux non è consentito eseguire un link
235 diretto ad una directory.
237 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
238 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
239 come avviene in altri sistemi operativi, dei file che contengono il
240 semplicemente il riferimento ad un altro file (o directory). In questo modo è
241 possibile effettuare link anche attraverso filesystem diversi e a directory, e
242 pure a file che non esistono ancora.
244 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
245 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
246 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
247 lettura del contenuto del medesimo e l'applicazione della funzione al file
248 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
249 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
250 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
251 alle informazioni del link invece che a quelle del file a cui esso fa
254 Le funzioni per operare sui link sono le seguenti, esse sono tutte dichiarate
255 nell'header file \texttt{unistd.h}.
258 \item \texttt{int symlink(const char * oldname, const char * newname)}
260 Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
261 nome \texttt{newname}.
263 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
264 di errore. La variabile \texttt{errno} viene settata secondo i codici di
265 errore standard di accesso ai files (trattati in dettaglio in
266 \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
269 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
271 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
272 su un filesystem montato readonly.
273 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
274 link è piena e non c'è ulteriore spazio disponibile.
275 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
276 \texttt{oldname} o di \texttt{newname}.
281 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
282 \label{sec:filedir_dir_creat_rem}
284 Per creare una nuova directory si può usare la seguente funzione, omonima
285 dell'analogo comando di shell \texttt{mkdir}; per accedere alla funzioni il
286 programma deve includere il file \texttt{sys/stat.h}.
289 \item \texttt{char * mkdir (const char * dirname, mode\_t mode)}
291 Questa funzione crea una nuova directory vuota con il nome indicato da
292 \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
293 può essere indicato con il pathname assoluto o relativo.
295 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
296 di errore \texttt{errno} viene settata secondo i codici di errore standard
297 di accesso ai files (trattati in dettaglio in
298 \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
300 \item \texttt{EACCESS}
301 Non c'è il permesso di scrittura per la directory in cui si vuole inserire
303 \item \texttt{EEXIST} Un file (o una directory) con quel nome essite di già.
304 \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
305 contiene troppi file. Sotto linux questo normalmente non avviene perchè il
306 filesystem standard consente la creazione di un numero di file maggiore di
307 quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
308 fare anche con filesystem di altri sistemi questo errore può presentarsi.
309 \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
311 \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
312 directory è su un filesystem montato readonly.
317 \subsection{Accesso alle directory}
318 \label{sec:filedir_dir_read}
320 Benchè le directory siano oggetti del filesystem come tutti gli altri non ha
321 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
322 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
323 contengono o ricerche sui medesimi.
325 Per accedere al contenuto delle directory si usano i cosiddetti
326 \textit{directory streams} (chiamati così per l'analogia con i file stream);
327 la funzione \texttt{opendir} apre uno di questi stream e la funzione
328 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
329 \textit{directory entries} (da distinguersi da quelle della cache di cui
330 parlavamo in \ref{sec:fileintr_vfs}) in una opportuna struttura
331 \texttt{struct dirent}.
334 \subsection{La directory di lavoro}
335 \label{sec:filedir_work_dir}
337 A ciascun processo è associato ad una directory nel filesystem che è chiamata
338 directory corrente o directory di lavoro (\textit{current working directory})
339 che è quella a cui si fa riferimento quando un filename è espresso in forma
340 relativa (relativa appunto a questa directory).
342 Quando un utente effettua il login questa directory viene settata alla
343 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
344 della shell consente di cambiarla a piacere, spostandosi da una directory ad
345 un'altra. Siccome la directory corrente resta la stessa quando viene creato
346 un processo figlio, la directory corrente della shell diventa anche la
347 directory corrente di qualunque comando da essa lanciato.
349 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
350 corrente. I prototipi di queste funzioni sono dichiarati in \texttt{unistd.h}.
353 \item \texttt{char * getcwd (char * buffer, size\_t size)}
355 Restituisce il filename completo della directory di lavoro corrente nella
356 stringa puntata da \texttt{buffer}, che deve essere precedentemente
357 allocata, per una dimensione massima di \texttt{size}. Si può anche
358 specificare un puntatore nullo come \textit{buffer}, nel qual caso la
359 stringa sarà allocata automaticamente per una dimensione pari a
360 \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
361 del pathname altrimenti. In questo caso si deve ricordare di disallocara la
362 stringa una volta cessato il suo utilizzo.
364 La funzione restituisce il puntatore \texttt{buffer} se riesce,
365 \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
366 \texttt{errno} è settata con i seguenti codici di errore:
369 \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
371 \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
372 lunghezza del pathname.
373 \item \texttt{EACCES} Manca il permesso di lettura o di ricerca su uno dei
374 componenti del pathname (cioè su una delle directory superiori alla
379 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
380 fatta per compatibilità all'indietro con BSD, che non consente di specificare
381 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
382 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byters, vedi
383 \ref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
384 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
385 contenere il nome del file, e questa è la ragione principale per cui questa
386 funzione è deprecata.
388 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
389 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
390 differenza che essa ritorna il valore della variabile di ambiente
391 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
392 riferimenti simbolici.
394 Come già detto in unix anche le directory sono file, è possibile pertanto
395 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
396 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
397 per cambiare directory di lavoro.
400 \item \texttt{int chdir (const char * pathname)}
402 Come dice il nome (che significa \textit{change directory}) questa funzione
403 serve a cambiare la directory di lavoro a quella speficata dal pathname
404 contenuto nella stringa \texttt{pathname}.
406 \item \texttt{int fchdir (int filedes)} analoga alla precedente, ma usa un
407 file descriptor invece del pathname.
410 Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
411 errore, in caso di errore \texttt{errno} viene settata secondo i codici di
412 errore standard di accesso ai files (trattati in dettaglio in
413 \ref{sec:filedir_access_control}) ai quali si aggiunge il codice
414 \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
422 \section{La manipolazione delle caratteristiche dei files}
423 \label{sec:filedir_infos}
426 Si ricordi che in unix non esistono i tipi di file e che non c'è nessun
427 supporto per le estensioni come parte del filesystem. Ciò non ostante molti
428 programmi adottano delle convenzioni per i nomi dei file, ad esempio il codice
429 C normalmente si mette in file con l'estensione .c, ma questa è, appunto, solo
433 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
434 \label{sec:filedir_stat}
436 \subsection{I tipi di file}
437 \label{sec:filedir_file_types}
439 \subsection{La dimensione dei file}
440 \label{sec:filedir_file_size}
442 \subsection{I tempi dei file}
443 \label{sec:filedir_file_times}
445 \subsection{La funzione \texttt{utime}}
446 \label{sec:filedir_utime}
450 \section{Il controllo di accesso ai file}
451 \label{sec:filedir_access_control}
454 \subsection{I flag \texttt{suid} e \texttt{sgid}}
455 \label{sec:filedir_suid_sgid}
457 \subsection{La titolarità di nuovi files e directory}
458 \label{sec:filedir_ownership}
460 \subsection{La funzione \texttt{access}}
461 \label{sec:filedir_access}
463 \subsection{La funzione \texttt{umask}}
464 \label{sec:filedir_umask}
466 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
467 \label{sec:filedir_chmod}
469 \subsection{Il flag \texttt{stiky}}
470 \label{sec:filedir_stiky}
472 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
473 \label{sec:filedir_chown}
477 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
478 %cosiddetto \textit{inode}; questo conterrà informazioni come il
479 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
480 %completo vedi \ntab), i permessi (vedi \ref{sec:file_perms}), le date (vedi
481 %\ref{sec:file_times}).