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 come è strutturato il
7 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 è
10 lasciato ai capitoli successivi.
13 \section{L'organizzazione di files e directories}
14 \label{sec:filedir_org}
16 L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
17 medesimi nell'albero descritto brevemente in \secref{sec:fileintr_overview};
18 una directory comunque, come già specificato in \secref{sec:fileintr_vfs}, è
19 solo un particolare tipo di file che contiene le informazioni che associano un
20 nome al contenuto. Per questo, anche se è usuale parlare di ``file in una
21 directory'' in realtà una directory contiene solo delle etichette per fare
22 riferimento ai file stessi.
24 I manuale delle librerie del C chiama i nomi contenuti nelle directory
25 \textsl{componenti} (in inglese \textit{file name components}), noi li
26 chiameremo più semplicemente nomi. Un file può essere indicato rispetto alla
27 directory corrente semplicemente specificando il nome da essa contenuto. Una
28 directory contiene semplicemente un elenco di questi nomi, che possono
29 corrispondere a un qualunque oggetto del filesystem, compresa un'altra
30 directory; l'albero viene appunto creato inserendo directory in altre
33 Il nome completo di file generico è composto da una serie di questi
34 \textsl{componenti} separati da una \texttt{/} (in Linux più \texttt{/}
35 consecutive sono considerate equivalenti ad una sola). Il nome completo di un
36 file viene usualmente chiamato \textit{pathname}, e anche se il manuale della
37 glibc depreca questo nome (poiché genererebbe confusione, dato che con
38 \textit{path} si indica anche un insieme di directory su cui effettuare una
39 ricerca, come quello in cui si cercano i comandi) l'uso è ormai così comune
40 che è senz'altro più chiaro dell'alternativa proposta.
42 Il processo con cui si associa ad un pathname uno specifico file è chiamato
43 risoluzione del nome (\textit{file name resolution} o \textit{pathname
44 resolution}). La risoluzione viene fatta esaminando il pathname da destra a
45 sinistra e localizzando ogni nome nella directory indicata dal nome
46 precedente: ovviamente perché il procedimento funzioni occorre che i nomi
47 indicati come directory esistano e siano effettivamente directory, inoltre i
48 permessi devono consentire l'accesso.
50 Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
51 del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
52 seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed
53 equivale alla directory radice dell'albero (come descritto in
54 \secref{sec:fileintr_overview}): in questo caso si parla di un pathname
55 \textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
56 cui torneremo più avanti in \secref{sec:filedir_work_dir}) ed il pathname è
57 detto \textsl{relativo}.
59 I nomi \texttt{.} e \texttt{..} hanno un significato speciale e vengono
60 inseriti in ogni directory, il primo fa riferimento alla directory corrente e
61 il secondo alla directory \textsl{genitore} (\textit{parent directory}) cioè
62 la directory che contiene il riferimento alla directory corrente; nel caso
63 questa sia la directory radice allora il riferimento è a se stessa.
66 \section{L'architettura di gestione dei file}
67 \label{sec:filedir_file_handling}
69 Per capire fino in fondo le proprietà di files e directories in un sistema
70 unix ed il funzionamento delle relative funzioni di manipolazione occorre una
71 breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è basato
72 un filesystem unix; in particolare si riprenderà, approfondendolo sul piano
73 dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui
74 abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione
75 nel kernel) in \secref{sec:fileintr_vfs}.
78 \subsection{Il funzionamento di un filesystem unix}
79 \label{sec:filedir_filesystem}
81 Come già accennato in \secref{sec:fileintr_overview} Linux (ed ogni unix in
82 generale) organizza i dati che tiene su disco attraverso l'uso di un
83 filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è
84 quella di poter supportare grazie al VFS una enorme quantità di filesystem
85 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
86 proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
87 daremo una descrizione a grandi linee che si adatta alle caratteristiche
88 comuni di un qualunque filesystem standard unix.
90 Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
91 partizione può contenere un filesystem; quest'ultimo è in genere strutturato
92 secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio a
93 disposizione per i dati e le directory.
98 \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
99 \label{fig:filedir_disk_filesys}
102 Se si va ad esaminare come è strutturata l'informazione all'interno di un
103 singolo filesystem (tralasciando le parti connesse alla strutturazione e al
104 funzionamento del filesystem stesso come il super-block) avremo una situazione
105 del tipo di quella esposta in \nfig.
109 \caption{Organizzazione di un filesystem}
110 \label{fig:filedir_filesys_detail}
112 da questa figura si evidenziano alcune caratteristiche su cui è bene porre
113 attenzione in quanto sono fondamentali per capire il funzionamento delle
114 funzioni che manipolano i file e le directory su cui torneremo fra poco; in
115 particolare è opportuno ricordare sempre che:
119 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
120 tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
121 fisici che contengono i dati e così via; le informazioni che la funzione
122 \texttt{stat} fornisce provengono dall'\textit{inode}; dentro una directory
123 si troverà solo il nome del file e il numero dell'\textit{inode} ad esso
124 associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
125 (traduzione approssimata dell'inglese \textit{directory entry}, che non
126 useremo anche per evitare confusione con le \textit{dentries} del kernel di
127 cui si parlava in \secref{sec:fileintr_vfs}).
129 \item Come mostrato in \curfig si possono avere più voci che puntano allo
130 stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
131 numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
132 solo quando questo contatore si annulla i dati del file vengono
133 effettivamente rimossi dal disco. Per questo la funzione per cancellare un
134 file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del
135 file, ma si limita a eliminare la relativa voce da una directory e
136 decrementare il numero di riferimenti nell'\textit{inode}.
138 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
139 nello stesso filesystem e non ci può essere una directory che contiene
140 riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
141 l'uso del comando \texttt{ln} (che crea una nuova voce per un file
142 esistente, con la funzione \texttt{link}) al filesystem corrente.
144 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
145 del file non deve essere spostato, viene semplicemente creata una nuova voce
146 per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
147 in cui opera normalmente il comando \texttt{mv} attraverso la funzione
152 Infine è bene avere presente che essendo file pure loro, esiste un numero di
153 riferimenti anche per le directories; per cui se ad esempio a partire dalla
154 situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir}
155 nella directory corrente avremo una situazione come quella in \nfig, dove per
156 chiarezza abbiamo aggiunto dei numeri di inode.
158 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
159 è referenziata dalla directory da cui si era partiti (in cui è inserita la
160 nuova voce che fa riferimento a \texttt{textdir}) e dalla voce \texttt{.}
161 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
162 che non contenga a sua volta altre directories. Al contempo la directory da
163 cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
164 adesso sarà referenziata anche dalla voce \texttt{..} di \texttt{textdir}.
167 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
168 \label{sec:filedir_link}
170 Una delle caratteristiche usate quando si opera con i file è quella di poter
171 creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
172 stesso file accedendovi da directory diverse. Questo è possibile anche in
173 ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
174 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
175 per fare questa operazione.
177 Come si è appena detto l'accesso al contenuto di un file su disco avviene
178 attraverso il suo inode, e il nome che si trova in una directory è solo una
179 etichetta associata ad un puntatore a detto inode. Questo significa che la
180 realizzazione di un link è immediata in quanto uno stesso file può avere tanti
181 nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo
182 stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una
183 particolare preferenza rispetto agli altri.
185 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
186 suole chiamare questo tipo di associazione un collegamento diretto (o
187 \textit{hard link}). Il prototipo della funzione e le sue caratteristiche
188 principali, come risultano dalla man page, sono le seguenti:
189 \begin{prototype}{unistd.h}
190 {int link(const char * oldpath, const char * newpath)}
191 Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath}
192 dandogli nome \texttt{newpath}.
194 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
195 di errore. La variabile \texttt{errno} viene settata secondo i seguenti
198 \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
200 \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e
201 \texttt{newpath} non supporta i link diretti, oppure \texttt{oldpath} è
203 \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori
204 dello spazio di indirizzi del processo.
205 \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
206 per attraversare le directories), vedi \secref{sec:filedir_access_control}
208 \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo.
209 \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath}
210 non esiste o è un link simbolico spezzato.
211 \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath}
213 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
214 completare l'operazione.
215 \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è
216 su un filesystem montato readonly.
217 \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di
219 \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il
220 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
221 \secref{sec:xxx_limits}).
222 \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione
223 di \texttt{oldpath} o \texttt{newpath}.
224 \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha
225 spazio per ulteriori voci.
226 \item \texttt{EIO} c'è stato un errore di input/output.
230 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
231 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
232 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
233 richiamato in diverse directory.
235 Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del
236 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
237 filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
238 il caso ad esempio del filesystem \texttt{vfat} di windows).
240 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
241 ma solo l'amministratore è in grado di creare un collegamento diretto ad
242 un'altra directory, questo lo si fa perché in questo caso è possibile creare
243 dei circoli nel filesystem (vedi \secref{sec:filedir_symlink}) che molti
244 programmi non sono in grado di gestire e la cui rimozione diventa estremamente
245 complicata (in genere occorre far girare il programma \texttt{fsck} per
246 riparare il filesystem); data la sua pericolosità in Linux questa
247 caratteristica è stata disabilitata, e la funzione restituisce l'errore
250 La rimozione di un file (o più precisamente della voce che lo referenzia) si
251 effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
253 \begin{prototype}{unistd.h}{int unlink(const char * pathname)}
254 Cancella il nome specificato dal pathname nella relativa directory e
255 decrementa il numero di riferimenti nel relativo inode. Nel caso di link
256 simbolico cancella il link simbolico; nel caso di socket, fifo o file di
257 dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
258 uno di questi oggetti possono continuare ad utilizzarlo.
260 La funzione restituisce zero in caso di successo e -1 per un errore, nel
261 qual caso il file non viene toccato. La variabile \texttt{errno} viene
262 settata secondo i seguenti codici di errore:
264 \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
265 per attraversare le directories), vedi \secref{sec:filedir_access_control}
267 \item \texttt{EPERM} il filesystem che contiene \texttt{pathname} non
268 consente l'operazione.
269 \item \texttt{EFAULT} la stringa passata come parametro è fuori dello spazio
270 di indirizzi del processo.
271 \item \texttt{ENAMETOOLONG} il pathname troppo lungo.
272 \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link
274 \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory.
275 \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory.
276 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
277 completare l'operazione.
278 \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola
280 \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del
282 \item \texttt{EIO} errore di input/output.
286 Per cancellare una voce in una directory è necessario avere il permesso di
287 scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
288 il diritto di esecuzione sulla directory che la contiene (torneremo in
289 dettaglio sui permessi e gli attributi fra poco), se inoltre lo
290 \textit{sticky} bit è settato occorrerà anche essere proprietari del file o
291 proprietari della directory (o root, per cui nessuna delle restrizioni è
294 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
295 della nome dalla directory e l'incremento/decremento del numero di riferimenti
296 nell'inode deve essere una operazione atomica (cioè non interrompibile da
297 altri) processi, per questo entrambe queste funzioni sono realizzate tramite
298 una singola system call.
300 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
301 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
302 count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
303 questo però si aggiunge una altra condizione, e cioè che non ci siano processi
304 che abbiano detto file aperto. Come accennato questa proprietà viene spesso
305 usata per essere sicuri di non lasciare file temporanei su disco in caso di
306 crash dei programmi; la tecnica è quella di aprire il file e chiamare
307 \texttt{unlink} subito dopo.
309 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
310 \label{sec:filedir_cre_canc}
312 Al contrario di quanto avviene con altri unix in Linux non è possibile usare
313 \texttt{unlink} sulle directory, per cancellare una directory si può usare la
314 funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
315 funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
316 per cancellare un file o una directory (e funziona anche per i sistemi che non
317 supportano i link diretti), che per i file è identica alla \texttt{unlink} e
318 per le directory è identica alla \texttt{rmdir}:
320 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
321 Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e
322 \texttt{rmdir} per le directory.
324 La funzione restituisce zero in caso di successo e -1 per un errore, nel
325 qual caso il file non viene toccato. Per i codici di errori vedi quanto
326 riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}.
329 Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il
330 vantaggio nell'uso di questa funzione al posto della chiamata successiva di
331 \texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in
332 questo modo non c'è la possibilità che un processo che cerchi di accedere al
333 nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante.
335 \begin{prototype}{stdio.h}
336 {int rename(const char *oldpath, const char *newpath)}
337 Rinomina un file, spostandolo fra directory diverse quando richiesto.
339 La funzione restituisce zero in caso di successo e -1 per un errore, nel
340 qual caso il file non viene toccato. La variabile \texttt{errno} viene
341 settata secondo i seguenti codici di errore:
343 \item \texttt{EFAULT} la stringa \texttt{filename} è fuori dello spazio di
344 indirizzi del processo.
345 \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
346 cui si vuole creare il nuovo link o una delle directory del pathname non
347 consente la ricerca (permesso di esecuzione).
348 \item \texttt{EPERM} il pathname indica una directory o il filesystem che
349 contiene \texttt{filename} non consente l'operazione.
350 \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura.
351 \item \texttt{ENAMETOOLONG} il pathname è troppo lungo.
352 \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
354 \item \texttt{ENOTDIR} Uno dei componenti del pathname non è una directory.
355 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
356 completare l'operazione.
357 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
359 \item \texttt{EISDIR}
361 \item \texttt{ENOTEMPTY}
363 \item \texttt{EINVAL}
364 \item \texttt{EMLINK}
365 \item \texttt{ENOSPC}
370 \subsection{I link simbolici}
371 \label{sec:filedir_sym_link}
373 Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
374 funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
375 in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
376 tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una
379 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
380 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
381 come avviene in altri sistemi operativi, dei file che contengono il
382 semplicemente il riferimento ad un altro file (o directory). In questo modo è
383 possibile effettuare link anche attraverso filesystem diversi e a directory, e
384 pure a file che non esistono ancora.
386 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
387 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
388 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
389 lettura del contenuto del medesimo e l'applicazione della funzione al file
390 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
391 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
392 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
393 alle informazioni del link invece che a quelle del file a cui esso fa
396 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
397 dichiarate nell'header file \texttt{unistd.h}.
399 \begin{prototype}{unistd.h}
400 {int symlink(const char * oldname, const char * newname)}
401 Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
402 nome \texttt{newname}.
404 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
405 di errore. La variabile \texttt{errno} viene settata secondo i codici di
406 errore standard di accesso ai files (trattati in dettaglio in
407 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
409 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
411 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
412 su un filesystem montato readonly.
413 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
414 link è piena e non c'è ulteriore spazio disponibile.
415 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
416 \texttt{oldname} o di \texttt{newname}.
420 Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare
421 un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
422 questa funzione è la:
424 \begin{prototype}{unistd.h}
425 {int readlink(const char * path, char * buff, size\_t size)}
426 Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer
427 \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
428 carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
429 piccolo per contenerla.
431 La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
432 -1 per un errore, in caso di errore. La variabile \texttt{errno} viene
433 settata secondo i codici di errore:
435 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
437 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
438 su un filesystem montato readonly.
439 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
440 link è piena e non c'è ulteriore spazio disponibile.
441 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
442 \texttt{oldname} o di \texttt{newname}.
447 \section{La manipolazione delle caratteristiche dei files}
448 \label{sec:filedir_infos}
450 Come spiegato in \secref{sec:filedir_file_handling} tutte le informazioni
451 generali relative alle caratteristiche di ciascun file sono mantenute
452 nell'inode. Vedremo in questa sezione come sia possibile accedervi usando la
453 funzione \texttt{stat} ed esamineremo alcune funzioni utilizzabili per
454 manipolare una parte di questa informazione. Tutto quello che invece riguarda
455 il meccanismo di controllo di accesso ad i file e le relative funzioni di
456 manipolazione sarà invece esaminanto in \secref{sec:filedir_access_control}.
459 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
460 \label{sec:filedir_stat}
462 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
463 delle funzioni \texttt{stat}, questa è la funzione che il comando \texttt{ls}
464 usa per poter stampare tutti i dati dei files; il prototipo della funzione è
466 \begin{prototype}{sys/stat.h}
467 {int stat(const char *file_name, struct stat *buf)}
469 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
470 di errore \texttt{errno} viene settato ai valori:
472 \item \texttt{EACCESS} Non c'è il permesso di accedere al file.
473 \item \texttt{ENOTDIR} Una componente del pathname non è una directory.
474 \item \texttt{EMLOOP} Ci sono troppi link simbolici nel pathname.
475 \item \texttt{EFAULT} I puntatori usati sono fuori dallo spazio di indirizzi
477 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
478 completare l'operazione.
479 \item \texttt{ENAMETOOLONG} Il filename è troppo lungo.
483 \subsection{I tipi di file}
484 \label{sec:filedir_file_types}
486 \subsection{La dimensione dei file}
487 \label{sec:filedir_file_size}
489 \subsection{I tempi dei file}
490 \label{sec:filedir_file_times}
492 \subsection{La funzione \texttt{utime}}
493 \label{sec:filedir_utime}
498 \section{Il controllo di accesso ai file}
499 \label{sec:filedir_access_control}
502 \subsection{I flag \texttt{suid} e \texttt{sgid}}
503 \label{sec:filedir_suid_sgid}
505 \subsection{La titolarità di nuovi files e directory}
506 \label{sec:filedir_ownership}
508 \subsection{La funzione \texttt{access}}
509 \label{sec:filedir_access}
511 \subsection{La funzione \texttt{umask}}
512 \label{sec:filedir_umask}
514 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
515 \label{sec:filedir_chmod}
517 \subsection{Il flag \texttt{sticky}}
518 \label{sec:filedir_sticky}
520 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
521 \label{sec:filedir_chown}
524 \section{La manipolazione delle directories}
525 \label{sec:filedir_dir_handling}
527 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
528 \label{sec:filedir_dir_creat_rem}
530 Per creare una nuova directory si può usare la seguente funzione, omonima
531 dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati
532 programma deve includere il file \texttt{sys/types.h}.
534 \begin{prototype}{sys/stat.h}
535 {int mkdir (const char * dirname, mode\_t mode)}
536 Questa funzione crea una nuova directory vuota con il nome indicato da
537 \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
538 può essere indicato con il pathname assoluto o relativo.
540 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
541 di errore \texttt{errno} viene settata secondo i codici di errore standard
542 di accesso ai files (trattati in dettaglio in
543 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
545 \item \texttt{EACCESS}
546 Non c'è il permesso di scrittura per la directory in cui si vuole inserire
548 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già.
549 \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
550 contiene troppi file. Sotto Linux questo normalmente non avviene perché il
551 filesystem standard consente la creazione di un numero di file maggiore di
552 quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
553 fare anche con filesystem di altri sistemi questo errore può presentarsi.
554 \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
556 \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
557 directory è su un filesystem montato readonly.
562 \subsection{Accesso alle directory}
563 \label{sec:filedir_dir_read}
565 Benché le directory siano oggetti del filesystem come tutti gli altri non ha
566 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
567 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
568 contengono o ricerche sui medesimi.
570 Per accedere al contenuto delle directory si usano i cosiddetti
571 \textit{directory streams} (chiamati così per l'analogia con i file stream);
572 la funzione \texttt{opendir} apre uno di questi stream e la funzione
573 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
574 \textit{directory entries} (da distinguersi da quelle della cache di cui
575 parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura
576 \texttt{struct dirent}.
579 \subsection{La directory di lavoro}
580 \label{sec:filedir_work_dir}
582 A ciascun processo è associato ad una directory nel filesystem che è chiamata
583 directory corrente o directory di lavoro (\textit{current working directory})
584 che è quella a cui si fa riferimento quando un filename è espresso in forma
585 relativa (relativa appunto a questa directory).
587 Quando un utente effettua il login questa directory viene settata alla
588 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
589 della shell consente di cambiarla a piacere, spostandosi da una directory ad
590 un'altra. Siccome la directory corrente resta la stessa quando viene creato
591 un processo figlio, la directory corrente della shell diventa anche la
592 directory corrente di qualunque comando da essa lanciato.
594 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
597 \begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
598 Restituisce il filename completo della directory di lavoro corrente nella
599 stringa puntata da \texttt{buffer}, che deve essere precedentemente
600 allocata, per una dimensione massima di \texttt{size}. Si può anche
601 specificare un puntatore nullo come \textit{buffer}, nel qual caso la
602 stringa sarà allocata automaticamente per una dimensione pari a
603 \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
604 del pathname altrimenti. In questo caso si deve ricordare di disallocare la
605 stringa una volta cessato il suo utilizzo.
607 La funzione restituisce il puntatore \texttt{buffer} se riesce,
608 \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
609 \texttt{errno} è settata con i seguenti codici di errore:
611 \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
613 \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
614 lunghezza del pathname.
615 \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei
616 componenti del pathname (cioè su una delle directory superiori alla
621 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
622 fatta per compatibilità all'indietro con BSD, che non consente di specificare
623 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
624 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
625 \secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
626 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
627 contenere il nome del file, e questa è la ragione principale per cui questa
628 funzione è deprecata.
630 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
631 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
632 differenza che essa ritorna il valore della variabile di ambiente
633 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
634 riferimenti simbolici.
636 Come già detto in unix anche le directory sono file, è possibile pertanto
637 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
638 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
639 per cambiare directory di lavoro.
641 \begin{prototype}{unistd.h}{int chdir (const char * pathname)}
642 Come dice il nome (che significa \textit{change directory}) questa funzione
643 serve a cambiare la directory di lavoro a quella specificata dal pathname
644 contenuto nella stringa \texttt{pathname}.
647 \begin{prototype}{unistd.h}{int fchdir (int filedes)}
648 Analoga alla precedente, ma usa un file descriptor invece del pathname.
650 Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
651 errore, in caso di errore \texttt{errno} viene settata secondo i codici di
652 errore standard di accesso ai files (trattati in dettaglio in
653 \secref{sec:filedir_access_control}) ai quali si aggiunge il codice
654 \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
661 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
662 %cosiddetto \textit{inode}; questo conterrà informazioni come il
663 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
664 %completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
665 %\secref{sec:file_times}).