1 \chapter{Files e directories}
2 \label{cha:files_and_dirs}
4 In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
5 file e directory, ed in particolare esamineremo come è strutturato il sistema
6 base di protezioni e controllo di accesso ai file, e tutta l'interfaccia che
7 permette la manipolazione dei vari attributi di file e directory. Tutto quello
8 che riguarda invece la manipolazione del contenuto dei file è lasciato ai
13 \section{Il controllo di accesso ai file}
14 \label{sec:filedir_access_control}
16 Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
17 del controllo di accesso ai file, che viene implementato per qualunque
18 filesystem standard. In questa sezione ne esamineremo i concetti essenziali e
19 le funzioni usate per gestirne i vari aspetti.
22 \subsection{I permessi per l'accesso ai file}
23 \label{sec:filedir_perm_overview}
25 Il controllo di accesso ai file in unix segue un modello abbastanza semplice,
26 ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre
27 livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
28 tipo unix, e non è detto che sia applicabile a un filesystem
29 qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
30 per il quale vengono assegnati in maniera fissa con un opzione in fase di
31 montaggio}. Esistono inoltre estensioni che permettono di implementare le
32 ACL (\textit{Access Control List}) che sono un meccanismo di controllo di
33 accesso molto più sofisticato.
35 Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
36 \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
37 identificatoti di utenti e gruppi (uid e gig) già accennato in
38 \secref{sec:intro_multiuser}, e un insieme di permessi che sono divisi in tre
39 classi, e cioè attribuiti rispettivamente al proprietario, a qualunque utente
40 faccia parte del gruppo cui appartiene il file, e a tutti gli altri utenti.
42 I permessi sono espressi da un insieme di 12 bit: di questi i nove meno
43 significativi sono usati a gruppi di tre per indicare i permessi base di
44 lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere
45 \textit{w}, \textit{r} \textit{x} nell'output di \cmd{ls}) applicabili
46 rispettivamente al proprietario, al gruppo, a tutti (una descrizione più
47 dettagliata dei vari permessi associati ai file è riportata in
48 \secref{sec:filedir_suid_sgid}). I restanti tre bit sono usati per indicare
49 alcune caratteristiche più complesse (\textit{suid}, \textit{sgid}, e
50 \textit{sticky}) su cui pure torneremo in seguito (vedi
51 \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}).
53 Tutte queste informazioni sono tenute per ciascun file nell'inode, in
54 opportuni bit del campo \var{st\_mode} della struttura letta da \func{stat}
55 (vedi \figref{fig:filedir_stat_struct}) che possono essere controllati con i
56 valori riportati in \ntab.
61 \caption{I bit deipermessi di accesso ai file, come definiti in
62 \texttt{<sys/stat.h>}}
63 \label{tab:file_bit_perm}
67 % Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
68 % confrontandoli con quelli del file e se l'operazione richiesta è compatibile
69 % con i permessi associati al file essa viene eseguita, altrimenti viene
70 % bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
71 % viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale
73 % pertanto accesso senza restrizione a qualunque file del sistema.
75 % In realtà il procedimento è più complesso di quanto descritto in maniera
76 % elementare qui; inoltre ad un processo sono associati diversi identificatori,
77 % torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}.
80 \subsection{I flag \texttt{suid} e \texttt{sgid}}
81 \label{sec:filedir_suid_sgid}
83 \subsection{La titolarità di nuovi files e directory}
84 \label{sec:filedir_ownership}
87 \subsection{La funzione \texttt{access}}
88 \label{sec:filedir_access}
91 \subsection{La funzione \texttt{umask}}
92 \label{sec:filedir_umask}
95 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
96 \label{sec:filedir_chmod}
98 \subsection{Il flag \texttt{sticky}}
99 \label{sec:filedir_sticky}
101 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
102 \label{sec:filedir_chown}
107 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
108 %cosiddetto \textit{inode}; questo conterrà informazioni come il
109 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
110 %completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
111 %\secref{sec:file_times}).
116 \section{La manipolazione di file e directory}
118 Le prime funzioni che considereremo sono quelle relative alla gestione di file
119 e directory, secondo le caratteristiche standard che essi presentano in un
120 filesystem unix, la cui struttura abbiamo esaminato in precedenza (vedi
121 \secref{sec:fileintr_filesystem}).
123 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
124 \label{sec:fileintr_link}
126 Una delle caratteristiche usate quando si opera con i file è quella di poter
127 creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
128 stesso file accedendovi da directory diverse. Questo è possibile anche in
129 ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
130 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
131 per fare questa operazione.
133 Come spiegato in \secref{sec:fileintr_architecture} l'accesso al contenuto di
134 un file su disco avviene attraverso il suo inode, e il nome che si trova in
135 una directory è solo una etichetta associata ad un puntatore a detto inode.
136 Questo significa che la realizzazione di un link è immediata in quanto uno
137 stesso file può avere tanti nomi diversi allo stesso tempo, dati da
138 altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
139 questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
141 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
142 suole chiamare questo tipo di associazione un collegamento diretto (o
143 \textit{hard link}). Il prototipo della funzione e le sue caratteristiche
144 principali, come risultano dalla man page, sono le seguenti:
145 \begin{prototype}{unistd.h}
146 {int link(const char * oldpath, const char * newpath)}
147 Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath}
148 dandogli nome \texttt{newpath}.
150 La funzione restituisce zero in caso di successo e -1 in caso di errore. La
151 variabile \texttt{errno} viene settata opportunamente, i principali codici
154 \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
156 \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e
157 \texttt{newpath} non supporta i link diretti o è una directory.
158 \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di
160 \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il
161 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
162 \secref{sec:xxx_limits}).
167 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
168 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
169 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
170 richiamato in diverse directory.
172 Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del
173 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
174 filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
175 il caso ad esempio del filesystem \texttt{vfat} di windows).
177 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
178 in alcuni filesystem solo l'amministratore è in grado di creare un
179 collegamento diretto ad un'altra directory, questo lo si fa perché in questo
180 caso è possibile creare dei circoli nel filesystem (vedi
181 \secref{sec:fileintr_symlink}) che molti programmi non sono in grado di
182 gestire e la cui rimozione diventa estremamente complicata (in genere occorre
183 far girare il programma \texttt{fsck} per riparare il filesystem); data la sua
184 pericolosità in generale nei filesystem usati in Linux questa caratteristica è
185 stata disabilitata, e la funzione restituisce l'errore \texttt{EPERM}.
187 La rimozione di un file (o più precisamente della voce che lo referenzia) si
188 effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
190 \begin{prototype}{unistd.h}{int unlink(const char * pathname)}
191 Cancella il nome specificato dal pathname nella relativa directory e
192 decrementa il numero di riferimenti nel relativo inode. Nel caso di link
193 simbolico cancella il link simbolico; nel caso di socket, fifo o file di
194 dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
195 uno di questi oggetti possono continuare ad utilizzarlo.
197 La funzione restituisce zero in caso di successo e -1 per un errore, nel
198 qual caso il file non viene toccato. La variabile \texttt{errno} viene
199 settata secondo i seguenti codici di errore:
201 \item \texttt{EISDIR} \var{pathname} si riferisce ad una directory
202 (valore specifico ritornato da linux che non consente l'uso di
203 \texttt{unlink} con le directory, e non conforme allo standard POSIX, che
204 prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia
205 consnetita o il processo non abbia privilegi sufficienti).
206 \item \texttt{EROFS} \var{pathname} è su un filesystem montato in sola
208 \item \texttt{EISDIR} \var{pathname} fa riferimento a una directory.
212 Per cancellare una voce in una directory è necessario avere il permesso di
213 scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
214 il diritto di esecuzione sulla directory che la contiene (torneremo in
215 dettaglio sui permessi e gli attributi fra poco), se inoltre lo
216 \textit{sticky} bit è settato occorrerà anche essere proprietari del file o
217 proprietari della directory (o root, per cui nessuna delle restrizioni è
220 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
221 della nome dalla directory e l'incremento/decremento del numero di riferimenti
222 nell'inode deve essere una operazione atomica (cioè non interrompibile da
223 altri) processi, per questo entrambe queste funzioni sono realizzate tramite
224 una singola system call.
226 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
227 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
228 count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
229 questo però si aggiunge una altra condizione, e cioè che non ci siano processi
230 che abbiano detto file aperto. Come accennato questa proprietà viene spesso
231 usata per essere sicuri di non lasciare file temporanei su disco in caso di
232 crash dei programmi; la tecnica è quella di aprire il file e chiamare
233 \texttt{unlink} subito dopo.
235 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
236 \label{sec:fileintr_remove}
238 Al contrario di quanto avviene con altri unix in Linux non è possibile usare
239 \texttt{unlink} sulle directory, per cancellare una directory si può usare la
240 funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
241 funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
242 per cancellare un file o una directory (e funziona anche per i sistemi che non
243 supportano i link diretti), che per i file è identica alla \texttt{unlink} e
244 per le directory è identica alla \texttt{rmdir}:
246 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
247 Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e
248 \texttt{rmdir} per le directory.
250 La funzione restituisce zero in caso di successo e -1 per un errore, nel
251 qual caso il file non viene toccato. Per i codici di errori vedi quanto
252 riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}.
255 Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il
256 vantaggio nell'uso di questa funzione al posto della chiamata successiva di
257 \texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in
258 questo modo non c'è la possibilità che un processo che cerchi di accedere al
259 nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante.
261 \begin{prototype}{stdio.h}
262 {int rename(const char *oldpath, const char *newpath)}
263 Rinomina un file, spostandolo fra directory diverse quando richiesto.
265 La funzione restituisce zero in caso di successo e -1 per un errore, nel
266 qual caso il file non viene toccato. La variabile \texttt{errno} viene
267 settata secondo i seguenti codici di errore:
269 \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre
270 \texttt{oldpath} non è una directory.
271 \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
273 \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e
275 \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da
276 parte di qualche processo (come directory di lavoro o come root) o del
277 sistema (come mount point).
278 \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di
279 \texttt{oldpath} o più in generale si è cercato di creare una directory
280 come sottodirectory di se stessa.
281 \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link
282 consentiti o è una directory e la directory che contiene \texttt{newpath}
283 ha già il massimo numero di link.
284 \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory
285 o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una
287 \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello
288 spazio di indirizzi del processo.
289 \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
290 cui si vuole creare il nuovo link o una delle directory del pathname non
291 consente la ricerca (permesso di esecuzione).
292 \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o
293 \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non
294 consentono rispettivamente la cancellazione e la creazione del file, o il
295 filesystem non supporta i link.
296 \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo.
297 \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
299 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
300 completare l'operazione.
301 \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura.
302 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
304 \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la
309 \subsection{I link simbolici}
310 \label{sec:fileintr_symlink}
312 Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
313 funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
314 in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
315 tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una
318 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
319 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
320 come avviene in altri sistemi operativi, dei file che contengono il
321 semplicemente il riferimento ad un altro file (o directory). In questo modo è
322 possibile effettuare link anche attraverso filesystem diversi e a directory, e
323 pure a file che non esistono ancora.
325 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
326 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
327 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
328 lettura del contenuto del medesimo e l'applicazione della funzione al file
329 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
330 o rinominare i file operano direttamente sul link simbolico (per l'elenco vedi
331 \ntab). Inoltre esistono funzioni apposite, come la \texttt{readlink} e la
332 \texttt{lstat} per accedere alle informazioni del link invece che a quelle del
333 file a cui esso fa riferimento.
335 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
336 dichiarate nell'header file \texttt{unistd.h}.
338 \begin{prototype}{unistd.h}
339 {int symlink(const char * oldname, const char * newname)}
340 Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
341 nome \texttt{newname}.
343 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
344 di errore. La variabile \texttt{errno} viene settata secondo i codici di
345 errore standard di accesso ai files (trattati in dettaglio in
346 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
348 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
350 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
351 su un filesystem montato readonly.
352 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
353 link è piena e non c'è ulteriore spazio disponibile.
354 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
355 \texttt{oldname} o di \texttt{newname}.
359 Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare
360 un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
361 questa funzione è la:
363 \begin{prototype}{unistd.h}
364 {int readlink(const char * path, char * buff, size\_t size)}
365 Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer
366 \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
367 carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
368 piccolo per contenerla.
370 La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
371 -1 per un errore, in caso di errore. La variabile \texttt{errno} viene
372 settata secondo i codici di errore:
374 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
376 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
377 su un filesystem montato readonly.
378 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
379 link è piena e non c'è ulteriore spazio disponibile.
380 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
381 \texttt{oldname} o di \texttt{newname}.
385 In \ntab\ si è riportato un elenco dei comportamenti delle varie funzioni che
386 operano sui file rispetto ai link simbolici; specificando quali seguono il
387 link simbolico e quali possono operare direttamente sul suo contenuto.
391 \begin{tabular}[c]{|l|c|c|}
393 Funzione & Segue il link & Non segue il link \\
396 \func{access} & $\bullet$ & \\
397 \func{chdir} & $\bullet$ & \\
398 \func{chmod} & $\bullet$ & \\
399 \func{chown} & & $\bullet$ \\
400 \func{creat} & $\bullet$ & \\
401 \func{exec} & $\bullet$ & \\
402 \func{lchown} & $\bullet$ & $\bullet$ \\
404 \func{lstat} & & $\bullet$ \\
405 \func{mkdir} & $\bullet$ & \\
406 \func{mkfifo} & $\bullet$ & \\
407 \func{mknod} & $\bullet$ & \\
408 \func{open} & $\bullet$ & \\
409 \func{opendir} & $\bullet$ & \\
410 \func{pathconf} & $\bullet$ & \\
411 \func{readlink} & & $\bullet$ \\
412 \func{remove} & & $\bullet$ \\
413 \func{rename} & & $\bullet$ \\
414 \func{stat} & $\bullet$ & \\
415 \func{truncate} & $\bullet$ & \\
416 \func{unlink} & & $\bullet$ \\
419 \caption{Uso dei link simbolici da parte di alcune funzioni.}
420 \label{tab:filedir_symb_effect}
422 si noti che non si è specificato il comportamento delle funzioni che operano
423 con i file descriptor, in quanto la gestione del link simbolico viene in
424 genere effttuata dalla funzione che restituisce il file descriptor
425 (normalmente la \func{open}).
429 \includegraphics[width=5cm]{img/link_loop.eps}
430 \caption{Esempio di loop nel filesystem creato con un link simbolico.}
431 \label{fig:filedir_link_loop}
434 Un caso comune che si può avere con i link simbolici è la creazione dei
435 cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta
436 la struttura della directory \file{/boot}. Come si vede si è creato al suo
437 interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
438 tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
439 bootloader estremamente avanzato in grado di accedere direttamente
440 attraverso vari filesystem al file da lanciare come sistema operativo) di
441 vedere i file in questa directory, che è montata su una partizione separata
442 (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
443 visti dal sistema operativo.}.
445 Questo può causare problemi per tutti quei programmi che effettuassero uno
446 scan di una directory senza tener conto dei link simbolici, in quel caso
447 infatti il loop nella directory
449 Un secondo punto da tenere presente è che un link simbolico può essere fatto
450 anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
451 nella nostra directory con un link del tipo:
453 $ln -s /tmp/tmp_file temporaneo
455 ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura
456 \file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola
457 lettura (ad esempio con \cmd{cat}) otterremmo:
460 cat: prova: No such file or directory
462 con un errore che sembra sbagliato, dato \cmd{ls} ci mostrerebbe l'esistenza
463 di \file{temporaneo}.
466 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
467 \label{sec:filedir_dir_creat_rem}
469 Per creare una nuova directory si può usare la seguente funzione, omonima
470 dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati
471 programma deve includere il file \texttt{sys/types.h}.
473 \begin{prototype}{sys/stat.h}
474 {int mkdir (const char * dirname, mode\_t mode)}
475 Questa funzione crea una nuova directory vuota con il nome indicato da
476 \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
477 può essere indicato con il pathname assoluto o relativo.
479 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
480 di errore \texttt{errno} viene settata secondo i codici di errore standard
481 di accesso ai files (trattati in dettaglio in
482 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
484 \item \texttt{EACCESS}
485 Non c'è il permesso di scrittura per la directory in cui si vuole inserire
487 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già.
488 \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
489 contiene troppi file. Sotto Linux questo normalmente non avviene perché il
490 filesystem standard consente la creazione di un numero di file maggiore di
491 quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
492 fare anche con filesystem di altri sistemi questo errore può presentarsi.
493 \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
495 \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
496 directory è su un filesystem montato readonly.
501 \subsection{Accesso alle directory}
502 \label{sec:filedir_dir_read}
504 Benché le directory siano oggetti del filesystem come tutti gli altri non ha
505 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
506 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
507 contengono o ricerche sui medesimi.
509 Per accedere al contenuto delle directory si usano i cosiddetti
510 \textit{directory streams} (chiamati così per l'analogia con i file stream);
511 la funzione \texttt{opendir} apre uno di questi stream e la funzione
512 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
513 \textit{directory entries} (da distinguersi da quelle della cache di cui
514 parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura
515 \texttt{struct dirent}.
518 \subsection{La directory di lavoro}
519 \label{sec:filedir_work_dir}
521 A ciascun processo è associato ad una directory nel filesystem che è chiamata
522 directory corrente o directory di lavoro (\textit{current working directory})
523 che è quella a cui si fa riferimento quando un filename è espresso in forma
524 relativa (relativa appunto a questa directory).
526 Quando un utente effettua il login questa directory viene settata alla
527 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
528 della shell consente di cambiarla a piacere, spostandosi da una directory ad
529 un'altra. Siccome la directory corrente resta la stessa quando viene creato
530 un processo figlio, la directory corrente della shell diventa anche la
531 directory corrente di qualunque comando da essa lanciato.
533 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
536 \begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
537 Restituisce il filename completo della directory di lavoro corrente nella
538 stringa puntata da \texttt{buffer}, che deve essere precedentemente
539 allocata, per una dimensione massima di \texttt{size}. Si può anche
540 specificare un puntatore nullo come \textit{buffer}, nel qual caso la
541 stringa sarà allocata automaticamente per una dimensione pari a
542 \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
543 del pathname altrimenti. In questo caso si deve ricordare di disallocare la
544 stringa una volta cessato il suo utilizzo.
546 La funzione restituisce il puntatore \texttt{buffer} se riesce,
547 \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
548 \texttt{errno} è settata con i seguenti codici di errore:
550 \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
552 \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
553 lunghezza del pathname.
554 \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei
555 componenti del pathname (cioè su una delle directory superiori alla
560 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
561 fatta per compatibilità all'indietro con BSD, che non consente di specificare
562 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
563 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
564 \secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
565 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
566 contenere il nome del file, e questa è la ragione principale per cui questa
567 funzione è deprecata.
569 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
570 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
571 differenza che essa ritorna il valore della variabile di ambiente
572 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
573 riferimenti simbolici.
575 Come già detto in unix anche le directory sono file, è possibile pertanto
576 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
577 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
578 per cambiare directory di lavoro.
580 \begin{prototype}{unistd.h}{int chdir (const char * pathname)}
581 Come dice il nome (che significa \textit{change directory}) questa funzione
582 serve a cambiare la directory di lavoro a quella specificata dal pathname
583 contenuto nella stringa \texttt{pathname}.
586 \begin{prototype}{unistd.h}{int fchdir (int filedes)}
587 Analoga alla precedente, ma usa un file descriptor invece del pathname.
589 Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
590 errore, in caso di errore \texttt{errno} viene settata secondo i codici di
591 errore standard di accesso ai files (trattati in dettaglio in
592 \secref{sec:filedir_access_control}) ai quali si aggiunge il codice
593 \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
599 \section{La manipolazione delle caratteristiche dei files}
600 \label{sec:filedir_infos}
602 Come spiegato in \secref{sec:fileintr_filesystem} tutte le informazioni
603 generali relative alle caratteristiche di ciascun file sono mantenute
604 nell'inode. Vedremo in questa sezione come sia possibile accedervi usando la
605 funzione \texttt{stat} ed esamineremo alcune funzioni utilizzabili per
606 manipolare una parte di questa informazione. Tutto quello che invece riguarda
607 il meccanismo di controllo di accesso ad i file e le relative funzioni di
608 manipolazione sarà invece esaminanto in \secref{sec:filedir_access_control}.
611 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
612 \label{sec:filedir_stat}
614 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
615 delle funzioni \func{stat}, che è la funzione che il comando \cmd{ls} usa
616 per poter stampare tutti i dati dei files. I prototipi di queste funzioni sono
619 \headdecl{sys/types.h}
620 \headdecl{sys/stat.h}
623 \funcdecl{int stat(const char *file\_name, struct stat *buf)} Legge le
624 informazione del file specificato da \var{file\_name} e le inserisce in
627 \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
628 \func{stat} eccetto che se il \var{file\_name} è un link simbolico vengono
629 lette le informazioni relativa ad esso e non al file a cui fa riferimento.
631 \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
632 eccetto che si usa con un file aperto, specificato tramite il suo file
633 descriptor \var{filedes}.
635 Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
636 caso di errore \texttt{errno} viene settato ai valori:
638 \item \texttt{EACCESS} non c'è il permesso di accedere al file.
639 \item \texttt{ENOTDIR} una componente del pathname non è una directory.
640 \item \texttt{EMLOOP} ci sono troppi link simbolici nel pathname.
641 \item \texttt{EFAULT} i puntatori usati sono fuori dallo spazio di indirizzi
643 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
644 completare l'operazione.
645 \item \texttt{ENAMETOOLONG} il filename è troppo lungo.
649 La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in
650 generale dipende dall'implementazione, la versione usata da Linux è mostrata
651 in \nfig, così come riportata dalla man page (in realtà la definizione
652 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
653 riservati per estensioni come tempi più precisi, o per il padding dei campi).
658 \begin{minipage}[c]{15cm}
659 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
661 dev_t st_dev; /* device */
662 ino_t st_ino; /* inode */
663 mode_t st_mode; /* protection */
664 nlink_t st_nlink; /* number of hard links */
665 uid_t st_uid; /* user ID of owner */
666 gid_t st_gid; /* group ID of owner */
667 dev_t st_rdev; /* device type (if inode device) */
668 off_t st_size; /* total size, in bytes */
669 unsigned long st_blksize; /* blocksize for filesystem I/O */
670 unsigned long st_blocks; /* number of blocks allocated */
671 time_t st_atime; /* time of last access */
672 time_t st_mtime; /* time of last modification */
673 time_t st_ctime; /* time of last change */
678 \caption{La struttura \texttt{stat} per la lettura delle informazioni dei
680 \label{fig:filedir_stat_struct}
683 Si noti come i vari membri della struttura siano specificati come tipi nativi
684 del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
685 \texttt{sys/types.h}).
688 \subsection{I tipi di file}
689 \label{sec:filedir_file_types}
691 Come riportato in \tabref{tab:fileintr_file_types} in Linux oltre ai file e
692 alle directory esistono vari altri oggetti che possono stare su un filesystem;
693 il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode}.
695 Dato che il valore numerico può variare a seconda delle implementazioni lo
696 standard POSIX definisce un insieme di macro per verificare il tipo di files,
697 queste venfono usate anche da Linux che supporta pure le estensioni per link
698 simbolici e socket definite da BDS, l'elenco è riportato in \ntab:
702 \begin{tabular}[c]{|l|l|}
704 Macro & Tipo del file \\
707 \macro{S\_ISREG(m)} & file normale \\
708 \macro{S\_ISDIR(m)} & directory \\
709 \macro{S\_ISCHR(m)} & device a caraetteri \\
710 \macro{S\_ISBLK(m)} & device a blocchi\\
711 \macro{S\_ISFIFO(m)} & fifo \\
712 \macro{S\_ISLNK(m)} & link simbolico \\
713 \macro{S\_ISSOCK(m)} & socket \\
716 \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h})}
717 \label{tab:filedir_file_type_macro}
720 Oltre a queste macro è possibile usare direttamente il valore di
721 \var{st\_mode} per ricavare il significato dei vari bit in esso memorizzati,
722 per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in
727 \begin{tabular}[c]{|l|c|l|}
729 Flag & Valore & Significato \\
732 \macro{S\_IFMT} & 0170000 & bitmask for the file type bitfields \\
733 \macro{S\_IFSOCK} & 0140000 & socket \\
734 \macro{S\_IFLNK} & 0120000 & symbolic link \\
735 \macro{S\_IFREG} & 0100000 & regular file \\
736 \macro{S\_IFBLK} & 0060000 & block device \\
737 \macro{S\_IFDIR} & 0040000 & directory \\
738 \macro{S\_IFCHR} & 0020000 & character device \\
739 \macro{S\_IFIFO} & 0010000 & fifo \\
740 \macro{S\_ISUID} & 0004000 & set UID bit \\
741 \macro{S\_ISGID} & 0002000 & set GID bit (see below) \\
742 \macro{S\_ISVTX} & 0001000 & sticky bit (see below) \\
743 \macro{S\_IRWXU} & 00700 & mask for file owner permissions \\
744 \macro{S\_IRUSR} & 00400 & owner has read permission \\
745 \macro{S\_IWUSR} & 00200 & owner has write permission \\
746 \macro{S\_IXUSR} & 00100 & owner has execute permission \\
747 \macro{S\_IRWXG} & 00070 & mask for group permissions \\
748 \macro{S\_IRGRP} & 00040 & group has read permission \\
749 \macro{S\_IWGRP} & 00020 & group has write permission \\
750 \macro{S\_IXGRP} & 00010 & group has execute permission \\
751 \macro{S\_IRWXO} & 00007 & mask for permissions for others (not in
753 \macro{S\_IROTH} & 00004 & others have read permission \\
754 \macro{S\_IWOTH} & 00002 & others have write permisson \\
755 \macro{S\_IXOTH} & 00001 & others have execute permission \\
758 \caption{Flag per il campo \var{st\_mode} (definite in
759 \texttt{sys/stat.h})}
760 \label{tab:filedir_file_mode_flags}
763 Il primo valore definisce la maschera dei bit usati nei quali viene
764 memorizzato il tipo di files, mentre gli altri possono essere usati per
765 effettuare delle selezioni sul tipo di file voluto, combinando opportunamente
766 i vari flag; ad esempio se si volesse controllare se un file è una directory o
767 un file ordinario si potrebbe definire la condizione:
768 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
769 #define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG))
771 in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
772 poi si effettua il confronto con la combinazione di tipi scelta.
774 \subsection{La dimensione dei file}
775 \label{sec:filedir_file_size}
777 Il membro \var{st\_size} contiene la dimensione del file in bytes (se il file
778 è un file normale, nel caso di un link simbolico al dimensione è quella del
779 pathname che contiene).
781 Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
782 bytes. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
783 i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
784 per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
785 dimensione inferiore sarebbe inefficiente.
787 Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
788 che corrisponda all'occupazione dello spazio su disco per via della possibile
789 esistenza dei cosiddetti \textsl{buchi} (detti normalmente \textit{holes}) che
790 si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
791 una \func{seek} (vedi \secref{sec:fileunix_lseek}) oltre la sua conclusione
794 In tal caso si avranno differenti risultati a seconda del modi in cui si
795 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
796 numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
797 legge dal file (ad esempio usando \cmd{wc -c}), dato che in tal caso per le
798 parti non scritte vengono restituiti degli zeri, si avrà lo stesso risultato
801 Se è sempre possibile allargare un file scrivendoci sopra od usando la
802 funzione \func{seek} per spostarsi oltre la sua fine. Esistono però anche casi
803 in cui si può avere bisogno di effettuare un troncamento scartando i dati al
804 di là della dimensione scelta come nuova fine del file.
806 Un file può essere troncato a zero aprendolo con il flag \macro{O\_TRUNC}, ma
807 questo è un caso particolare; per qualunque altra dimensione si possono usare
810 \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
811 length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad
812 un valore massimo specificato da \var{lenght}.
814 \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate}
815 eccetto che si usa con un file aperto, specificato tramite il suo file
818 Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
819 caso di errore \texttt{errno} viene settato ai valori:
821 \item \texttt{EACCESS} non c'è il permesso di accedere al file.
822 \item \texttt{ENOTDIR} una componente del pathname non è una directory.
823 \item \texttt{EMLOOP} ci sono troppi link simbolici nel pathname.
824 \item \texttt{EFAULT} i puntatori usati sono fuori dallo spazio di indirizzi
826 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
827 completare l'operazione.
828 \item \texttt{ENOENT} il file non esiste.
829 \item \texttt{ENAMETOOLONG} il filename è troppo lungo.
833 Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
834 perduti; il comportamento in caso di lunghezza inferiore non è specificato e
835 dipende dall'implementazione: il file può essere lasciato invariato o esteso
836 fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con
837 zeri (e in genere si ha la creazione di un hole nel file).
840 \subsection{I tempi dei file}
841 \label{sec:filedir_file_times}
843 Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
844 nell'inode insieme agli altri attibuti del file e possono essere letti tramite
845 la funzione \func{stat}, che li restituisce attraverso tre campi della
846 struttura in \figref{fig:filedir_stat_struct}. Il significato di detti tempi e
847 dei relativi campi è riportato nello schema in \ntab:
851 \begin{tabular}[c]{|c|l|l|c|}
853 Membro & Significato & Funzione&opzione \\
856 \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\
857 \var{st\_mtime}& ultima modifica ai dati del file &\func{write}& default\\
858 \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod},
859 \func{utime} & \cmd{-c} \\
862 \caption{I tre tempi associati a ciascun file}
863 \label{tab:filedir_file_times}
866 Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
867 modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di
868 cambiamento di stato (il \textit{chage time} \var{st\_ctime}). Il primo
869 infatti fa riferimento ad una modifica del contenuto di un file, mentre il
870 secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la
871 funzione \func{link} e molte altre che vedremo in seguito) che modificano solo
872 le informazioni contenute nell'inode senza toccare il file, diventa necessario
873 l'utilizzo di un altro tempo.
875 Il sistema non tiene conto dell'ultimo accesso all'inode, pertanto funzioni
876 come \func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il
877 tempo di ultimo accesso viene di solito usato per cancellare i file che non
878 servono più dopo un certo lasso di tempo (ad esempio \cmd{leafnode} cancella i
879 vecchi articoli sulla base di questo tempo).
881 Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere
882 quali file necessitano di essere ricompilati o (talvolta insieme anche al
883 tempo di cambiamento di stato) per decidere quali file devono essere
884 archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni
885 \cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato
886 nell'ultima colonna di \curtab.
888 L'effetto delle varie funzioni di manipolazione dei file sui tempi è
889 illustrato in \ntab. Si sono riportati gli effetti sia per il file a cui si fa
890 riferimento, sia per la directory che lo contiene; questi ultimi possono
891 essere capiti se si tiene conto di quanto già detto, e cioè che anche le
892 directory sono files, che il sistema tratta in maniera del tutto analoga agli
895 Per questo motivo tutte le volte che compiremo una operazione su un file che
896 comporta una modifica della sua directory entry, andremo anche a scrivere
897 sulla directory che lo contiene cambiandone il tempo di modifica. Un esempio
898 di questo può essere la cancellazione di un file, mentre leggere o scrivere o
899 cambiarne i permessi ha effetti solo sui tempi del file.
904 \begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
906 \multicolumn{1}{|c|}{Funzione}
907 &\multicolumn{3}{p{2cm}}{File o directory di riferimento}
908 &\multicolumn{3}{p{2cm}}{Directory genitrice del riferimento}
909 &\multicolumn{1}{|c|}{Note} \\
911 & \textsl{(a)} & \textsl{(m)}& \textsl{(c)}
912 & \textsl{(a)} & \textsl{(m)}& \textsl{(c)}& \\
915 \func{chmod}, \func{fchmod}
916 & & &$\bullet$& & & & \\
917 \func{chown}, \func{fchown}
918 & & &$\bullet$& & & & \\
920 &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& con
921 \macro{O\_CREATE} \\ \func{creat}
922 & &$\bullet$&$\bullet$& &$\bullet$&$\bullet$&
923 con \macro{O\_TRUNC} \\ \func{exec}
924 &$\bullet$& & & & & & \\
926 & & &$\bullet$& & & & \\
928 & & &$\bullet$& &$\bullet$&$\bullet$& \\
930 &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& \\
932 &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& \\
934 &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& con
935 \macro{O\_CREATE} \\ \func{open}
936 & &$\bullet$&$\bullet$& & & & con
937 \macro{O\_TRUNC} \\ \func{pipe}
938 &$\bullet$&$\bullet$&$\bullet$& & & & \\
940 &$\bullet$& & & & & & \\
942 & & &$\bullet$& &$\bullet$&$\bullet$& using
943 \func{unlink}\\ \func{remove}
944 & & & & &$\bullet$&$\bullet$& using
945 \func{rmdir}\\ \func{rename}
946 & & &$\bullet$& &$\bullet$&$\bullet$& per entrambi
947 gli argomenti\\ \func{rmdir}
948 & & & & &$\bullet$&$\bullet$& \\
949 \func{truncate}, \func{ftruncate}
950 & &$\bullet$&$\bullet$& & & & \\
952 & & &$\bullet$& &$\bullet$&$\bullet$& \\
954 &$\bullet$&$\bullet$&$\bullet$& & & & \\
956 & &$\bullet$&$\bullet$& & & & \\
959 \caption{Effetti delle varie funzioni su tempi di ultimo accesso
960 \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento
962 \label{tab:filedir_times_effects}
965 Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
966 creazione del file, usato da molti altri sistemi operativi, che in unix non
970 \subsection{La funzione \texttt{utime}}
971 \label{sec:filedir_utime}
973 I tempi di ultimo accesso e modifica possono essere cambiati usando la
974 funzione \func{utime}, il cui prototipo è:
976 \begin{prototype}{utime.h}
977 {int utime(const char * filename, struct utimbuf *times)}
979 Cambia i tempi di ultimo accesso e modifica dell'inode specificato da
980 \var{filename} secondo i campi \var{actime} e \var{modtime} di \var{times}. Se
981 questa è \macro{NULL} allora viene usato il tempo corrente.
983 La funzione restituisce zero in caso di successo e -1 in caso di errore, nel
984 qual caso \var{errno} è settata opportunamente.
986 \item \texttt{EACCESS} non si ha il permesso di scrittura sul file.
987 \item \texttt{ENOENT} \var{filename} non esiste.
991 La struttura \var{utimebuf} usata da \func{utime} è definita come:
992 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
994 time_t actime; /* access time */
995 time_t modtime; /* modification time */
999 L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
1000 cosa è l'argomento \var{times}; se è \textit{NULL} la funzione setta il tempo
1001 corrente ed è sufficiente avere accesso in scrittura al file; se invece si è
1002 specificato un valore la funzione avrà successo solo se si è proprietari del
1003 file (o si hanno i privilegi di amministratore).
1005 Si tenga presente che non è comunque possibile specificare il tempo di
1006 cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
1007 volte che si modifica l'inode (quindi anche alla chiamata di \func{utime}).
1008 Questo serve anche come misura di sicurezza per evitare che si possa
1009 modificare un file nascondendo completamente le proprie tracce. In realtà la
1010 cosa resta possibile, se si è in grado di accedere al device, scrivendo
1011 direttamente sul disco senza passare attraverso il filesystem, ma ovviamente è
1012 molto più complicato da realizzare.