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 della 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 o è una directory.
202 \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori
203 dello spazio di indirizzi del processo.
204 \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
205 per attraversare le directories), vedi \secref{sec:filedir_access_control}
207 \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo.
208 \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath}
209 non esiste o è un link simbolico spezzato.
210 \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath}
212 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
213 completare l'operazione.
214 \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è
215 su un filesystem montato readonly.
216 \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di
218 \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il
219 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
220 \secref{sec:xxx_limits}).
221 \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione
222 di \texttt{oldpath} o \texttt{newpath}.
223 \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha
224 spazio per ulteriori voci.
225 \item \texttt{EIO} c'è stato un errore di input/output.
229 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
230 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
231 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
232 richiamato in diverse directory.
234 Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del
235 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
236 filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
237 il caso ad esempio del filesystem \texttt{vfat} di windows).
239 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
240 ma solo l'amministratore è in grado di creare un collegamento diretto ad
241 un'altra directory, questo lo si fa perché in questo caso è possibile creare
242 dei circoli nel filesystem (vedi \secref{sec:filedir_symlink}) che molti
243 programmi non sono in grado di gestire e la cui rimozione diventa estremamente
244 complicata (in genere occorre far girare il programma \texttt{fsck} per
245 riparare il filesystem); data la sua pericolosità in Linux questa
246 caratteristica è stata disabilitata, e la funzione restituisce l'errore
249 La rimozione di un file (o più precisamente della voce che lo referenzia) si
250 effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
252 \begin{prototype}{unistd.h}{int unlink(const char * pathname)}
253 Cancella il nome specificato dal pathname nella relativa directory e
254 decrementa il numero di riferimenti nel relativo inode. Nel caso di link
255 simbolico cancella il link simbolico; nel caso di socket, fifo o file di
256 dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
257 uno di questi oggetti possono continuare ad utilizzarlo.
259 La funzione restituisce zero in caso di successo e -1 per un errore, nel
260 qual caso il file non viene toccato. La variabile \texttt{errno} viene
261 settata secondo i seguenti codici di errore:
263 \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
264 per attraversare le directories), vedi \secref{sec:filedir_access_control}
266 \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory
267 (valore specifico ritornato da linux che non consente l'uso di
268 \texttt{unlink} con le directory, e non conforme allo standard POSIX, che
269 prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia
270 consnetita o il processo non abbia privilegi sufficienti).
271 \item \texttt{EFAULT} la stringa
272 passata come parametro è fuori dello spazio di indirizzi del processo.
273 \item \texttt{ENAMETOOLONG} il pathname troppo lungo.
274 \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link
276 \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory.
277 \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory.
278 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
279 completare l'operazione.
280 \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola
282 \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del
284 \item \texttt{EIO} errore di input/output.
288 Per cancellare una voce in una directory è necessario avere il permesso di
289 scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
290 il diritto di esecuzione sulla directory che la contiene (torneremo in
291 dettaglio sui permessi e gli attributi fra poco), se inoltre lo
292 \textit{sticky} bit è settato occorrerà anche essere proprietari del file o
293 proprietari della directory (o root, per cui nessuna delle restrizioni è
296 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
297 della nome dalla directory e l'incremento/decremento del numero di riferimenti
298 nell'inode deve essere una operazione atomica (cioè non interrompibile da
299 altri) processi, per questo entrambe queste funzioni sono realizzate tramite
300 una singola system call.
302 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
303 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
304 count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
305 questo però si aggiunge una altra condizione, e cioè che non ci siano processi
306 che abbiano detto file aperto. Come accennato questa proprietà viene spesso
307 usata per essere sicuri di non lasciare file temporanei su disco in caso di
308 crash dei programmi; la tecnica è quella di aprire il file e chiamare
309 \texttt{unlink} subito dopo.
311 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
312 \label{sec:filedir_cre_canc}
314 Al contrario di quanto avviene con altri unix in Linux non è possibile usare
315 \texttt{unlink} sulle directory, per cancellare una directory si può usare la
316 funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
317 funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
318 per cancellare un file o una directory (e funziona anche per i sistemi che non
319 supportano i link diretti), che per i file è identica alla \texttt{unlink} e
320 per le directory è identica alla \texttt{rmdir}:
322 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
323 Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e
324 \texttt{rmdir} per le directory.
326 La funzione restituisce zero in caso di successo e -1 per un errore, nel
327 qual caso il file non viene toccato. Per i codici di errori vedi quanto
328 riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}.
331 Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il
332 vantaggio nell'uso di questa funzione al posto della chiamata successiva di
333 \texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in
334 questo modo non c'è la possibilità che un processo che cerchi di accedere al
335 nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante.
337 \begin{prototype}{stdio.h}
338 {int rename(const char *oldpath, const char *newpath)}
339 Rinomina un file, spostandolo fra directory diverse quando richiesto.
341 La funzione restituisce zero in caso di successo e -1 per un errore, nel
342 qual caso il file non viene toccato. La variabile \texttt{errno} viene
343 settata secondo i seguenti codici di errore:
345 \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre
346 \texttt{oldpath} non è una directory.
347 \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
349 \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e
351 \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da
352 parte di qualche processo (come directory di lavoro o come root) o del
353 sistema (come mount point).
354 \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di
355 \texttt{oldpath} o più in generale si è cercato di creare una directory
356 come sottodirectory di se stessa.
357 \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link
358 consentiti o è una directory e la directory che contiene \texttt{newpath}
359 ha già il massimo numero di link.
360 \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory
361 o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una
363 \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello
364 spazio di indirizzi del processo.
365 \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
366 cui si vuole creare il nuovo link o una delle directory del pathname non
367 consente la ricerca (permesso di esecuzione).
368 \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o
369 \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non
370 consentono rispettivamente la cancellazione e la creazione del file, o il
371 filesystem non supporta i link.
372 \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo.
373 \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
375 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
376 completare l'operazione.
377 \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura.
378 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
380 \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la
385 \subsection{I link simbolici}
386 \label{sec:filedir_sym_link}
388 Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
389 funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
390 in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
391 tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una
394 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
395 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
396 come avviene in altri sistemi operativi, dei file che contengono il
397 semplicemente il riferimento ad un altro file (o directory). In questo modo è
398 possibile effettuare link anche attraverso filesystem diversi e a directory, e
399 pure a file che non esistono ancora.
401 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
402 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
403 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
404 lettura del contenuto del medesimo e l'applicazione della funzione al file
405 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
406 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
407 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
408 alle informazioni del link invece che a quelle del file a cui esso fa
411 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
412 dichiarate nell'header file \texttt{unistd.h}.
414 \begin{prototype}{unistd.h}
415 {int symlink(const char * oldname, const char * newname)}
416 Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
417 nome \texttt{newname}.
419 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
420 di errore. La variabile \texttt{errno} viene settata secondo i codici di
421 errore standard di accesso ai files (trattati in dettaglio in
422 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
424 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
426 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
427 su un filesystem montato readonly.
428 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
429 link è piena e non c'è ulteriore spazio disponibile.
430 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
431 \texttt{oldname} o di \texttt{newname}.
435 Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare
436 un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
437 questa funzione è la:
439 \begin{prototype}{unistd.h}
440 {int readlink(const char * path, char * buff, size\_t size)}
441 Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer
442 \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
443 carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
444 piccolo per contenerla.
446 La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
447 -1 per un errore, in caso di errore. La variabile \texttt{errno} viene
448 settata secondo i codici di errore:
450 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
452 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
453 su un filesystem montato readonly.
454 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
455 link è piena e non c'è ulteriore spazio disponibile.
456 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
457 \texttt{oldname} o di \texttt{newname}.
462 \section{La manipolazione delle caratteristiche dei files}
463 \label{sec:filedir_infos}
465 Come spiegato in \secref{sec:filedir_file_handling} tutte le informazioni
466 generali relative alle caratteristiche di ciascun file sono mantenute
467 nell'inode. Vedremo in questa sezione come sia possibile accedervi usando la
468 funzione \texttt{stat} ed esamineremo alcune funzioni utilizzabili per
469 manipolare una parte di questa informazione. Tutto quello che invece riguarda
470 il meccanismo di controllo di accesso ad i file e le relative funzioni di
471 manipolazione sarà invece esaminanto in \secref{sec:filedir_access_control}.
474 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
475 \label{sec:filedir_stat}
477 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
478 delle funzioni \texttt{stat}, questa è la funzione che il comando \texttt{ls}
479 usa per poter stampare tutti i dati dei files; il prototipo della funzione è
481 \begin{prototype}{unistd.h}
482 {int stat(const char *file\_name, struct stat *buf)}
484 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
485 di errore \texttt{errno} viene settato ai valori:
487 \item \texttt{EACCESS} Non c'è il permesso di accedere al file.
488 \item \texttt{ENOTDIR} Una componente del pathname non è una directory.
489 \item \texttt{EMLOOP} Ci sono troppi link simbolici nel pathname.
490 \item \texttt{EFAULT} I puntatori usati sono fuori dallo spazio di indirizzi
492 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
493 completare l'operazione.
494 \item \texttt{ENAMETOOLONG} Il filename è troppo lungo.
498 La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in
499 generale dipende dall'implementazione, la versione usata da Linux è mostrata
500 in \nfig, così come riportata dalla man page (in realtà la definizione
501 effettivamente usata nel kernel dipende dall'archietettura e ha altri campi
502 riservati per estensioni come tempo più precisi, o per il padding dei campi).
504 \begin{figure}[!htbp]
508 dev_t st_dev; /* device */
509 ino_t st_ino; /* inode */
510 mode_t st_mode; /* protection */
511 nlink_t st_nlink; /* number of hard links */
512 uid_t st_uid; /* user ID of owner */
513 gid_t st_gid; /* group ID of owner */
514 dev_t st_rdev; /* device type (if inode device) */
515 off_t st_size; /* total size, in bytes */
516 unsigned long st_blksize; /* blocksize for filesystem I/O */
517 unsigned long st_blocks; /* number of blocks allocated */
518 time_t st_atime; /* time of last access */
519 time_t st_mtime; /* time of last modification */
520 time_t st_ctime; /* time of last change */
523 \caption{La struttura \texttt{stat} per la lettura delle informazioni dei
525 \label{fig:sock_sa_gen_struct}
528 Si noti come i vari membri della struttura siano specificati come tipi nativi
529 del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
530 \texttt{sys/types.h})
534 \subsection{I tipi di file}
535 \label{sec:filedir_file_types}
537 Come riportato in \tabref{tab:fileintr_file_types} in linux oltre ai file e
538 alle directory esistono vari altri oggetti che possono stare su un filesystem;
539 il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode},
540 dato che il valore numerico può variare a seconda delle implementazioni
543 \subsection{La dimensione dei file}
544 \label{sec:filedir_file_size}
546 \subsection{I tempi dei file}
547 \label{sec:filedir_file_times}
549 \subsection{La funzione \texttt{utime}}
550 \label{sec:filedir_utime}
555 \section{Il controllo di accesso ai file}
556 \label{sec:filedir_access_control}
559 \subsection{I flag \texttt{suid} e \texttt{sgid}}
560 \label{sec:filedir_suid_sgid}
562 \subsection{La titolarità di nuovi files e directory}
563 \label{sec:filedir_ownership}
565 \subsection{La funzione \texttt{access}}
566 \label{sec:filedir_access}
568 \subsection{La funzione \texttt{umask}}
569 \label{sec:filedir_umask}
571 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
572 \label{sec:filedir_chmod}
574 \subsection{Il flag \texttt{sticky}}
575 \label{sec:filedir_sticky}
577 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
578 \label{sec:filedir_chown}
581 \section{La manipolazione delle directories}
582 \label{sec:filedir_dir_handling}
584 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
585 \label{sec:filedir_dir_creat_rem}
587 Per creare una nuova directory si può usare la seguente funzione, omonima
588 dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati
589 programma deve includere il file \texttt{sys/types.h}.
591 \begin{prototype}{sys/stat.h}
592 {int mkdir (const char * dirname, mode\_t mode)}
593 Questa funzione crea una nuova directory vuota con il nome indicato da
594 \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
595 può essere indicato con il pathname assoluto o relativo.
597 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
598 di errore \texttt{errno} viene settata secondo i codici di errore standard
599 di accesso ai files (trattati in dettaglio in
600 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
602 \item \texttt{EACCESS}
603 Non c'è il permesso di scrittura per la directory in cui si vuole inserire
605 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già.
606 \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
607 contiene troppi file. Sotto Linux questo normalmente non avviene perché il
608 filesystem standard consente la creazione di un numero di file maggiore di
609 quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
610 fare anche con filesystem di altri sistemi questo errore può presentarsi.
611 \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
613 \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
614 directory è su un filesystem montato readonly.
619 \subsection{Accesso alle directory}
620 \label{sec:filedir_dir_read}
622 Benché le directory siano oggetti del filesystem come tutti gli altri non ha
623 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
624 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
625 contengono o ricerche sui medesimi.
627 Per accedere al contenuto delle directory si usano i cosiddetti
628 \textit{directory streams} (chiamati così per l'analogia con i file stream);
629 la funzione \texttt{opendir} apre uno di questi stream e la funzione
630 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
631 \textit{directory entries} (da distinguersi da quelle della cache di cui
632 parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura
633 \texttt{struct dirent}.
636 \subsection{La directory di lavoro}
637 \label{sec:filedir_work_dir}
639 A ciascun processo è associato ad una directory nel filesystem che è chiamata
640 directory corrente o directory di lavoro (\textit{current working directory})
641 che è quella a cui si fa riferimento quando un filename è espresso in forma
642 relativa (relativa appunto a questa directory).
644 Quando un utente effettua il login questa directory viene settata alla
645 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
646 della shell consente di cambiarla a piacere, spostandosi da una directory ad
647 un'altra. Siccome la directory corrente resta la stessa quando viene creato
648 un processo figlio, la directory corrente della shell diventa anche la
649 directory corrente di qualunque comando da essa lanciato.
651 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
654 \begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
655 Restituisce il filename completo della directory di lavoro corrente nella
656 stringa puntata da \texttt{buffer}, che deve essere precedentemente
657 allocata, per una dimensione massima di \texttt{size}. Si può anche
658 specificare un puntatore nullo come \textit{buffer}, nel qual caso la
659 stringa sarà allocata automaticamente per una dimensione pari a
660 \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
661 del pathname altrimenti. In questo caso si deve ricordare di disallocare la
662 stringa una volta cessato il suo utilizzo.
664 La funzione restituisce il puntatore \texttt{buffer} se riesce,
665 \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
666 \texttt{errno} è settata con i seguenti codici di errore:
668 \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
670 \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
671 lunghezza del pathname.
672 \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei
673 componenti del pathname (cioè su una delle directory superiori alla
678 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
679 fatta per compatibilità all'indietro con BSD, che non consente di specificare
680 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
681 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
682 \secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
683 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
684 contenere il nome del file, e questa è la ragione principale per cui questa
685 funzione è deprecata.
687 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
688 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
689 differenza che essa ritorna il valore della variabile di ambiente
690 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
691 riferimenti simbolici.
693 Come già detto in unix anche le directory sono file, è possibile pertanto
694 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
695 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
696 per cambiare directory di lavoro.
698 \begin{prototype}{unistd.h}{int chdir (const char * pathname)}
699 Come dice il nome (che significa \textit{change directory}) questa funzione
700 serve a cambiare la directory di lavoro a quella specificata dal pathname
701 contenuto nella stringa \texttt{pathname}.
704 \begin{prototype}{unistd.h}{int fchdir (int filedes)}
705 Analoga alla precedente, ma usa un file descriptor invece del pathname.
707 Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
708 errore, in caso di errore \texttt{errno} viene settata secondo i codici di
709 errore standard di accesso ai files (trattati in dettaglio in
710 \secref{sec:filedir_access_control}) ai quali si aggiunge il codice
711 \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
718 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
719 %cosiddetto \textit{inode}; questo conterrà informazioni come il
720 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
721 %completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
722 %\secref{sec:file_times}).