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