1 \chapter{I files: l'architettura}
2 \label{cha:files_intro}
4 Uno dei concetti fondamentali della architettura di unix è il cosiddetto
5 \textit{everything is a file}, cioè il fatto che l'accesso ai vari dispositivi
6 di input/output del computer viene effettuato attraverso un'interfaccia
7 astratta che tratta le periferiche allo stesso modo degli usuali file di dati.
9 Questo significa che si può accedere cioè a qualunque periferica del computer,
10 dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
11 cosiddetti file di dispositivo (i \textit{device files}). Questi sono dei file
12 speciali agendo sui quali i programmi possono leggere, scrivere e compiere
13 operazioni direttamente sulle periferiche, usando le stesse funzioni che si
14 usano per i normali file di dati.
16 In questo capitolo forniremo un'introduzione all'architettura della gestione
17 dei file, sia nelle sue caratteristiche generiche comuni a tutti gli unix, che
18 nelle particolarità che ha la specifica implementazione usata da Linux. Al
19 comtempo tratteremo l'organizzazione dei file in un sistema unix-like, e le
20 varie caratteristiche distintive.
24 \section{L'organizzazione di files e directories}
25 \label{sec:filedir_org}
27 Visto il ruolo fondamentale che i files vengono ad assumere in un sistema
28 unix-like, è anzitutto opportuno fornire un'introduzione dettagliata su come
29 essi vengono organizzati all'interno del sistema.
32 \subsection{Una breve introduzione}
33 \label{sec:fileintr_org_intro}
35 Partiamo allora da come viene strutturata nel sistema la disposizione dei
36 file: per potervi accedere il kernel usa una apposita interfaccia che permetta
37 di strutturare l'informazione tenuta sullo spazio grezzo disponibile sui
38 dischi, cioè quello che si chiama un \textit{filesystem}\footnote{useremo per
39 brevità questo nome al posto della più prolissa traduzione italiana sistema
40 di file}, che descriviremo in dettaglio in \secref{sec:fileintr_vfs}.
42 Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
43 memorizzati all'interno del disco stesso, strutturando l'informazione in files
44 e directory. Per poter accedere ai file contenuti in un disco occorrerà
45 perciò attivare il filesystem, questo viene fatto \textsl{montando} il disco
46 (o la partizione del disco).
48 %In generale un filesystem piazzerà opportunamente sul disco dei blocchi di
49 %informazioni riservate che tengono conto degli inodes allocati, di quelli
50 %liberi, e delle posizioni fisiche su disco dei dati contenuti nei files, per
52 In unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
53 file vengono tenuti all'interno di un unico albero la cui radice (la directory
54 di \textit{root}) viene montata all'avvio. Pertanto un file viene identificato
55 dall'utente usando quello che viene chiamato \textit{pathname}, cioè il
56 percorso che si deve fare per accedere al file.
58 Dopo la fase di inizializzazione il kernel riceve dal boot loader
59 l'indicazione di quale dispositivo contiene il filesystem da usare come punto
60 di partenza e questo viene montato come radice dell'albero (cioè nella
61 directory \texttt{/}); tutti gli ulteriori dischi devono poi essere inseriti
62 nell'albero utilizzando opportune subdirectory.
64 Alcuni filesystem speciali (come \texttt{/proc} che contiene un'interfaccia ad
65 alcune strutture interne del kernel) sono generati automaticamente dal kernel
66 stesso, ma anche essi devono essere montati all'interno dell'albero.
68 All'interno dello stesso albero si potranno poi inserire anche gli altri
69 oggetti visti attraverso l'interfaccia che manipola i files come le FIFO, i
70 link, i socket e gli stessi i file di dispositivo (questi ultimi, per
71 convenzione, sono inseriti nella directory \texttt{/dev}).
74 \subsection{La struttura di file e directories}
75 \label{sec:fileintr_filedir_struct}
77 L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
78 medesimi nell'albero descritto brevemente in \secref{sec:fileintr_org_intro};
79 una directory comunque, come già specificato in \secref{sec:fileintr_vfs}, è
80 solo un particolare tipo di file che contiene le informazioni che associano un
81 nome al contenuto. Per questo, anche se è usuale parlare di ``file in una
82 directory'' in realtà una directory contiene solo delle etichette per fare
83 riferimento ai file stessi.
85 I manuale delle glibc chiama i nomi contenuti nelle directory
86 \textsl{componenti} (in inglese \textit{file name components}), noi li
87 chiameremo più semplicemente nomi. Un file può essere indicato rispetto alla
88 directory corrente semplicemente specificando il nome da essa contenuto. Una
89 directory contiene semplicemente un elenco di questi nomi, che possono
90 corrispondere a un qualunque oggetto del filesystem, compresa un'altra
91 directory; l'albero viene appunto creato inserendo directory in altre
94 Il nome completo di file generico è composto da una serie di questi
95 \textsl{componenti} separati da una \texttt{/} (in Linux più \texttt{/}
96 consecutive sono considerate equivalenti ad una sola). Il nome completo di un
97 file viene usualmente chiamato \textit{pathname}, e anche se il manuale della
98 glibc depreca questo nome (poiché genererebbe confusione, dato che con
99 \textit{path} si indica anche un insieme di directory su cui effettuare una
100 ricerca, come quello in cui si cercano i comandi) l'uso è ormai così comune
101 che è senz'altro più chiaro dell'alternativa proposta.
103 Il processo con cui si associa ad un pathname uno specifico file è chiamato
104 risoluzione del nome (\textit{file name resolution} o \textit{pathname
105 resolution}). La risoluzione viene fatta esaminando il pathname da destra a
106 sinistra e localizzando ogni nome nella directory indicata dal nome
107 precedente: ovviamente perché il procedimento funzioni occorre che i nomi
108 indicati come directory esistano e siano effettivamente directory, inoltre i
109 permessi devono consentire l'accesso.
111 Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
112 del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
113 seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed
114 equivale alla directory radice dell'albero (come descritto in
115 \secref{sec:fileintr_overview}): in questo caso si parla di un pathname
116 \textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
117 cui torneremo più avanti in \secref{sec:filedir_work_dir}) ed il pathname è
118 detto \textsl{relativo}.
120 I nomi \texttt{.} e \texttt{..} hanno un significato speciale e vengono
121 inseriti in ogni directory, il primo fa riferimento alla directory corrente e
122 il secondo alla directory \textsl{genitore} (\textit{parent directory}) cioè
123 la directory che contiene il riferimento alla directory corrente; nel caso
124 questa sia la directory radice allora il riferimento è a se stessa.
127 % \subsection{Il controllo di accesso}
128 % \label{sec:fileintr_access_ctrl}
131 \subsection{I tipi di files}
132 \label{sec:fileintr_file_types}
134 Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
135 sono implementati come oggetti del \textit{Virtual File System} e sono
136 presenti in tutti i filesystem unix-like utilizzabili con Linux. L'elenco dei
137 vari tipi di file definiti dal Virtual File System è il seguente:
141 \begin{tabular}[c]{l l p{7cm}}
142 \multicolumn{2}{c}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
144 \textit{regular file} & \textsl{file normale} &
145 un file che contiene dei dati (l'accezione normale di file) \\
146 \textit{directory} & \textsl{cartella o direttorio} &
147 un file che contiene una lista di nomi associati a degli inodes \\
148 \textit{symbolic link} & \textsl{collegamento simbolico} &
149 un file che contiene un riferimento ad un altro file/directory \\
150 \textit{char device} & \textsl{dispositivo a caratteri} &
151 un file che identifica una periferica ad accesso sequenziale \\
152 \textit{block device} & \textsl{dispositivo a blocchi} &
153 un file che identifica una periferica ad accesso diretto \\
154 \textit{fifo} & \textsl{tubo} &
155 un file speciale che identifica una linea di comunicazione software
157 \textit{socket} & \textsl{manicotto} &
158 un file speciale che identifica una linea di comunicazione software
162 \caption{Tipologia dei file definiti nel VFS}
163 \label{tab:fileintr_file_types}
167 Si tenga ben presente che tutto ciò non ha nulla a che fare con la
168 classificazione sui tipi di file (che in questo caso sono sempre file di dati)
169 in base al loro contenuto, o tipo di accesso.
171 Una delle differenze principali con altri sistemi operativi (come il VMS o
172 Windows) è che per Unix tutti i file di dati sono identici e contengono un
173 flusso continuo di bytes; non esiste cioè differenza per come vengono visti
174 dal sistema file di diverso contenuto o formato (come nel caso di quella fra
175 file di testo e binari che c'è in Windows) né c'è una strutturazione a record
176 per il cosiddetto ``accesso diretto'' come nel caso del VMS.
178 % della serie 2.4 è disponibile una forma di accesso diretto ai dischi il
179 % \textit{raw access} che però non ha nulla a che fare con questo).
181 Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
182 codificata in maniera diversa da Windows o MacIntosh, in particolare il fine
183 riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
184 (\verb|\r|) del mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
185 problemi qualora nei programmi si facciano assunzioni sul terminatore della
189 \subsection{Le due interfacce ai file}
190 \label{sec:fileintr_io_api}
192 In unix le modalità di accesso ai file e le relative interfacce di
193 programmazione sono due, basate su due diversi meccanismi con cui è possibile
194 accedere al loro contenuto.
196 La prima è l'interfaccia standard di unix, quella che il manuale delle glibc
197 chiama interfaccia dei descrittore di file (o \textit{file descriptor}). È
198 un'interfaccia specifica di unix e provvede un accesso non bufferizzato.
200 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
201 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
202 direttamente le system call del kernel (in realtà il kernel effettua al suo
203 interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
204 dispositivi); i file descriptors sono rappresentati da numeri interi (cioè
205 semplici variabili di tipo \texttt{int}). L'interfaccia è definita
206 nell'header \texttt{unistd.h}.
208 La seconda interfaccia è quella che il manuale della glibc chiama degli
209 \textit{stream}, essa provvede funzioni più evolute e un accesso bufferizzato
210 (controllato dalla implementazione fatta dalle librerie del C). Questa è
211 l'interfaccia standard usata dal linguaggio C e perciò si trova anche su tutti
212 i sistemi non Unix. Gli stream sono oggetti complessi e sono rappresentati da
213 puntatori ad un opportuna struttura definita dalle librerie del C, si accede
214 ad essi sempre in maniera indiretta utilizzando il tipo \texttt{FILE *}.
215 L'interfaccia è definita nell'header \texttt{stdio.h}.
217 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
218 altri oggetti del VFS (pipes, socket, device), ma per poter accedere alle
219 operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre
220 usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
221 devono essere usati i file descriptor se si vuole ricorrere a modalità
222 speciali di I/O come il polling o il non-bloccante (vedi
223 \secref{sec:file_xxx}).
225 Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
226 dei file descriptor, che tratta tutti i file nello stesso modo, con
227 l'eccezione di poter scegliere tra diversi stili di bufferizzazione. Il
228 maggior vantaggio degli stream è che l'interfaccia per le operazioni di
229 input/output è enormemente più ricca di quella dei file descriptor, che
230 provvedono solo funzioni elementari per la lettura/scrittura diretta di
231 blocchi di bytes. In particolare gli stream dispongono di tutte le funzioni
232 di formattazione per l'input e l'output adatte per manipolare anche i dati in
233 forma di linee o singoli caratteri.
235 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
236 standard di unix, è sempre possibile estrarre il file descriptor da uno stream
237 ed eseguirvi operazioni di basso livello, o associare in un secondo tempo uno
238 stream ad un file descriptor.
240 In generale, se non necessitano specificatamente le funzionalità di basso
241 livello, è opportuno usare sempre gli stream per la loro maggiore portabilità
242 essendo questi ultimi definiti nello standard ANSI C; l'interfaccia con i file
243 descriptor invece segue solo lo standard POSIX.1 dei sistemi unix ed è
244 pertanto di portabilità più limitata.
246 \subsection{Caratteristiche specifiche dei file in unix}
247 \label{sec:fileint_unix_spec}
249 Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
250 specifiche di Unix che devono essere tenute in conto nell'accesso ai file. È
251 infatti normale che più processi o programmi possano accedere
252 contemporaneamente allo stesso file e devono poter eseguire le loro operazioni
253 indipendentemente da quello che fanno gli altri processi.
255 Per questo motivo le strutture usate per all'accesso ai file sono relative al
256 processo che effettua l'accesso. All'apertura di ogni file infatti viene
257 creata all'interno del processo una apposita struttura in cui sono memorizzati
258 tutti gli attributi del medesimo, che viene utilizzata per tutte le
259 operazioni. Questa è una struttura che resta locale al processo stesso; in
260 questo modo processi diversi possono usare le proprie strutture locali per
261 accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
264 Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
265 sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
266 file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
267 successiva. Essa è rappresentata da un numero intero che indica il numero di
268 bytes dall'inizio del file, che viene (a meno che non si apra il file in
269 append) inizializzato a zero all'apertura del medesimo.
271 Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
272 ogni processo avrà la sua posizione corrente nel file, che non sarà
273 influenzata da quello che altri processi possono fare. Anzi, aprire un file
274 significa appunto creare ed inizializzare una tale struttura, per cui se si
275 apre due volte lo stesso file all'interno dello stesso processo, si otterranno
276 due file descriptor o due stream che avranno ancora una posizione corrente nel
277 file assolutamente indipendente.
279 Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
280 accesso è un riferimento all'inode del file, pertanto anche se il file viene
281 cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
282 dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
283 chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
284 in dettaglio in \secref{sec:filedir_link}) aprire un file provvisorio per
285 cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
286 file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
287 saranno disponibili per tutto il tempo in cui il processo è attivo.
289 Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
290 esaminando in dettaglio come tutto ciò viene realizzato.
292 Si ricordi infine che in unix non esistono i tipi di file e che non c'è nessun
293 supporto per le estensioni come parte del filesystem. Ciò non ostante molti
294 programmi adottano delle convenzioni per i nomi dei file, ad esempio il codice
295 C normalmente si mette in file con l'estensione .c, ma questa è, appunto, solo
300 \section{L'architettura della gestione dei file}
301 \label{sec:filedir_file_handling}
303 Per capire fino in fondo le proprietà di files e directories in un sistema
304 unix ed il funzionamento delle relative funzioni di manipolazione occorre una
305 breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è basato
306 un filesystem unix; in particolare si riprenderà, approfondendolo sul piano
307 dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui
308 abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione
309 nel kernel) in \secref{sec:fileintr_vfs}.
311 In particolare occorre tenere presente dov'è che si situa la divisione
312 fondamentale fra kernel space e user space che tracciavamo al
313 \capref{cha:intro_unix}.
316 \subsection{Il \textit{virtual filesystem} di Linux}
317 \label{sec:fileintr_vfs}
319 Esamineremo adesso come viene implementato l'accesso ai files in Linux. Questa
320 sezione riporta informazioni sui dettagli di come il kernel gestisce i files.
321 L'argomento è abbastanza ``esoterico'' e questa sezione può essere saltata ad
322 una prima lettura; è bene però tenere presente che vengono introdotti qui
323 alcuni termini che potranno comparire in seguito, come \textit{inode},
324 \textit{dentry}, \textit{dcache}.
326 In Linux il concetto di \textit{everything is a file} è stato implementato
327 attraverso il \textit{virtual filesystem} (da qui in avanti VFS) che è
328 l'interfaccia che il kernel rende disponibile ai programmi in user space
329 attraverso la quale vengono manipolati i files; esso provvede un livello di
330 indirezione che permette di collegare le operazioni di manipolazione sui files
331 alle operazioni di I/O e gestisce l'organizzazione di questi ultimi nei vari
332 modi in cui diversi filesystem la effettuano, permettendo la coesistenza
333 di filesystem differenti all'interno dello stesso albero delle directory
335 Quando un processo esegue una system call che opera su un file il kernel
336 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
337 manipolazioni sulle strutture generiche e ridirigendo la chiamata alla
338 opportune routine del filesystem specifico a cui si fa riferimento, saranno
339 queste a chiamare le funzioni di piu basso livello che eseguono le operazioni
340 di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig.
345 \caption{Schema delle operazioni del VFS}
346 \label{fig:fileintro_VFS_scheme}
349 La funzione più importante implementata dal VFS è la system call \texttt{open}
350 che permette di aprire un file. Dato un pathname viene eseguita una ricerca
351 dentro la \textit{directory entry cache} (in breve \textit{dcache}),
352 una tabella di hash che contiene tutte le \textit{directory entry} (in breve
353 \textit{dentry}) che permette di associare in maniera rapida ed efficiente il
354 pathname a una specifica dentry.
356 Una singola dentry contiene in genere il puntatore ad un \textit{inode};
357 quest'ultimo è la struttura base che sta sul disco e che identifica un singolo
358 oggetto del VFS sia esso un file ordinario, una directory, una FIFO, un file
359 di dispositivo, o una qualsiasi altra cosa che possa essere rappresentata dal
360 VFS (sui tipi di ``files'' possibili torneremo in seguito). A ciascuno di essi
361 è associata pure una struttura che sta in memoria, e che oltre alle
362 informazioni sullo specifico file contiene pure il riferimento alle funzioni
363 (i \textsl{metodi}) da usare per poterlo manipolare.
365 Le dentries ``vivono'' in memoria e non vengono mai salvate su disco, vengono
366 usate per motivi di velocità, gli inodes invece stanno su disco e vengono
367 copiati in memoria quando serve, ed ogni cambiamento viene copiato
368 all'indietro sul disco, gli inodes che stanno in memoria sono inodes del VFS
369 ed è ad essi che puntano le singole dentry.
371 La dcache costituisce perciò una sorta di vista completa di tutto l'albero dei
372 files, ovviamente per non riempire tutta la memoria questa vista è parziale
373 (la dcache cioè contiene solo le dentry per i file per i quali è stato
374 richiesto l'accesso), quando si vuole risolvere un nuovo pathname il VFS deve
375 creare una nuova dentry e caricare l'inode corrispondente in memoria.
377 Questo procedimento viene eseguito dal metodo \texttt{lookup()} dell'inode
378 della directory che contiene il file; questo viene installato nelle relative
379 strutture in memoria quando si effettua il montaggio lo specifico filesystem
380 su cui l'inode va a vivere.
382 Una volta che il VFS ha a disposizione la dentry (ed il relativo inode)
383 diventa possibile accedere alle varie operazioni sul file come la
384 \texttt{open} per aprire il file o la \texttt{stat} per leggere i dati
385 dell'inode e passarli in user space.
387 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
388 una struttura di tipo \texttt{file} in cui viene inserito un puntatore alla
389 dentry e una struttura \verb|f_ops| che contiene i puntatori ai metodi che
390 implementano le operazioni disponibili sul file. In questo modo i processi in
391 user space possono accedere alle operazioni attraverso detti metodi, che
392 saranno diversi a seconda del tipo di file (o dispositivo) aperto (su questo
393 torneremo in dettaglio in \secref{sec:fileunix_fd}). Un elenco delle operazioni
394 previste dal kernel è riportato in \ntab.
398 \begin{tabular}[c]{c p{7cm}}
399 \textbf{funzione} & \textbf{operazione} \\
401 \textit{open} & apre il file \\
402 \textit{read} & legge dal file \\
403 \textit{write} & scrive sul file \\
404 \textit{llseek} & sposta la posizione corrente sul file \\
405 \textit{ioctl} & accede alle operazioni di controllo
406 (tramite la \texttt{ioctl})\\
407 \textit{readdir} & per leggere il contenuto di una directory \\
409 \textit{mmap} & chiamata dalla system call \texttt{mmap}.
410 mappa il file in memoria\\
411 \textit{release} & chiamata quando l'ultima referenza a un file
413 \textit{fsync} & chiamata dalla system call \texttt{fsync} \\
414 \textit{fasync} & chiamate da \texttt{fcntl} quando è abilitato
415 il modo asincrono per l'I/O su file. \\
418 \caption{Operazioni sui file definite nel VFS.}
419 \label{tab:fileintr_file_operations}
422 In questo modo per ciascun file diventano utilizzabili una serie di operazioni
423 (non è dette che tutte siano disponibili), che costituiscono l'interfaccia
424 astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad
425 utilizzare la opportuna routine dichiarata in \verb|f_ops| appropriata al tipo
426 di file in questione.
428 Così sarà possibile scrivere sulla porta seriale come su un file di dati
429 normale; ovviamente certe operazioni (nel caso della seriale ad esempio la
430 \textit{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
431 diversi filesystem (come quelli usati da Windows o MacOs) è immediato e
432 (relativamente) trasparente per l'utente ed il programmatore.
435 \subsection{Il funzionamento di un filesystem unix}
436 \label{sec:filedir_filesystem}
438 Come già accennato in \secref{sec:fileintr_overview} Linux (ed ogni unix in
439 generale) organizza i dati che tiene su disco attraverso l'uso di un
440 filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è
441 quella di poter supportare grazie al VFS una enorme quantità di filesystem
442 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
443 proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
444 daremo una descrizione a grandi linee che si adatta alle caratteristiche
445 comuni di un qualunque filesystem standard unix.
447 Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
448 partizione può contenere un filesystem; quest'ultimo è in genere strutturato
449 secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio a
450 disposizione per i dati e le directory.
455 \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
456 \label{fig:filedir_disk_filesys}
459 Se si va ad esaminare come è strutturata l'informazione all'interno di un
460 singolo filesystem (tralasciando le parti connesse alla strutturazione e al
461 funzionamento del filesystem stesso come il super-block) avremo una situazione
462 del tipo di quella esposta in \nfig.
466 \caption{Organizzazione di un filesystem}
467 \label{fig:filedir_filesys_detail}
469 da questa figura si evidenziano alcune caratteristiche su cui è bene porre
470 attenzione in quanto sono fondamentali per capire il funzionamento delle
471 funzioni che manipolano i file e le directory su cui torneremo fra poco; in
472 particolare è opportuno ricordare sempre che:
476 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
477 tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
478 fisici che contengono i dati e così via; le informazioni che la funzione
479 \texttt{stat} fornisce provengono dall'\textit{inode}; dentro una directory
480 si troverà solo il nome del file e il numero dell'\textit{inode} ad esso
481 associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
482 (traduzione approssimata dell'inglese \textit{directory entry}, che non
483 useremo anche per evitare confusione con le \textit{dentries} del kernel di
484 cui si parlava in \secref{sec:fileintr_vfs}).
486 \item Come mostrato in \curfig si possono avere più voci che puntano allo
487 stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
488 numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
489 solo quando questo contatore si annulla i dati del file vengono
490 effettivamente rimossi dal disco. Per questo la funzione per cancellare un
491 file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del
492 file, ma si limita a eliminare la relativa voce da una directory e
493 decrementare il numero di riferimenti nell'\textit{inode}.
495 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
496 nello stesso filesystem e non ci può essere una directory che contiene
497 riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
498 l'uso del comando \texttt{ln} (che crea una nuova voce per un file
499 esistente, con la funzione \texttt{link}) al filesystem corrente.
501 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
502 del file non deve essere spostato, viene semplicemente creata una nuova voce
503 per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
504 in cui opera normalmente il comando \texttt{mv} attraverso la funzione
509 Infine è bene avere presente che essendo file pure loro, esiste un numero di
510 riferimenti anche per le directories; per cui se ad esempio a partire dalla
511 situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir}
512 nella directory corrente avremo una situazione come quella in \nfig, dove per
513 chiarezza abbiamo aggiunto dei numeri di inode.
515 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
516 è referenziata dalla directory da cui si era partiti (in cui è inserita la
517 nuova voce che fa riferimento a \texttt{textdir}) e dalla voce \texttt{.}
518 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
519 che non contenga a sua volta altre directories. Al contempo la directory da
520 cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
521 adesso sarà referenziata anche dalla voce \texttt{..} di \texttt{textdir}.
524 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
525 \label{sec:filedir_link}
527 Una delle caratteristiche usate quando si opera con i file è quella di poter
528 creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
529 stesso file accedendovi da directory diverse. Questo è possibile anche in
530 ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
531 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
532 per fare questa operazione.
534 Come si è appena detto l'accesso al contenuto di un file su disco avviene
535 attraverso il suo inode, e il nome che si trova in una directory è solo una
536 etichetta associata ad un puntatore a detto inode. Questo significa che la
537 realizzazione di un link è immediata in quanto uno stesso file può avere tanti
538 nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo
539 stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una
540 particolare preferenza rispetto agli altri.
542 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
543 suole chiamare questo tipo di associazione un collegamento diretto (o
544 \textit{hard link}). Il prototipo della funzione e le sue caratteristiche
545 principali, come risultano dalla man page, sono le seguenti:
546 \begin{prototype}{unistd.h}
547 {int link(const char * oldpath, const char * newpath)}
548 Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath}
549 dandogli nome \texttt{newpath}.
551 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
552 di errore. La variabile \texttt{errno} viene settata secondo i seguenti
555 \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
557 \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e
558 \texttt{newpath} non supporta i link diretti o è una directory.
559 \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori
560 dello spazio di indirizzi del processo.
561 \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
562 per attraversare le directories), vedi \secref{sec:filedir_access_control}
564 \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo.
565 \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath}
566 non esiste o è un link simbolico spezzato.
567 \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath}
569 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
570 completare l'operazione.
571 \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è
572 su un filesystem montato readonly.
573 \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di
575 \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il
576 numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
577 \secref{sec:xxx_limits}).
578 \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione
579 di \texttt{oldpath} o \texttt{newpath}.
580 \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha
581 spazio per ulteriori voci.
582 \item \texttt{EIO} c'è stato un errore di input/output.
586 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
587 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
588 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
589 richiamato in diverse directory.
591 Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del
592 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
593 filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
594 il caso ad esempio del filesystem \texttt{vfat} di windows).
596 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
597 ma solo l'amministratore è in grado di creare un collegamento diretto ad
598 un'altra directory, questo lo si fa perché in questo caso è possibile creare
599 dei circoli nel filesystem (vedi \secref{sec:filedir_symlink}) che molti
600 programmi non sono in grado di gestire e la cui rimozione diventa estremamente
601 complicata (in genere occorre far girare il programma \texttt{fsck} per
602 riparare il filesystem); data la sua pericolosità in Linux questa
603 caratteristica è stata disabilitata, e la funzione restituisce l'errore
606 La rimozione di un file (o più precisamente della voce che lo referenzia) si
607 effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
609 \begin{prototype}{unistd.h}{int unlink(const char * pathname)}
610 Cancella il nome specificato dal pathname nella relativa directory e
611 decrementa il numero di riferimenti nel relativo inode. Nel caso di link
612 simbolico cancella il link simbolico; nel caso di socket, fifo o file di
613 dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
614 uno di questi oggetti possono continuare ad utilizzarlo.
616 La funzione restituisce zero in caso di successo e -1 per un errore, nel
617 qual caso il file non viene toccato. La variabile \texttt{errno} viene
618 settata secondo i seguenti codici di errore:
620 \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
621 per attraversare le directories), vedi \secref{sec:filedir_access_control}
623 \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory
624 (valore specifico ritornato da linux che non consente l'uso di
625 \texttt{unlink} con le directory, e non conforme allo standard POSIX, che
626 prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia
627 consnetita o il processo non abbia privilegi sufficienti).
628 \item \texttt{EFAULT} la stringa
629 passata come parametro è fuori dello spazio di indirizzi del processo.
630 \item \texttt{ENAMETOOLONG} il pathname troppo lungo.
631 \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link
633 \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory.
634 \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory.
635 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
636 completare l'operazione.
637 \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola
639 \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del
641 \item \texttt{EIO} errore di input/output.
645 Per cancellare una voce in una directory è necessario avere il permesso di
646 scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
647 il diritto di esecuzione sulla directory che la contiene (torneremo in
648 dettaglio sui permessi e gli attributi fra poco), se inoltre lo
649 \textit{sticky} bit è settato occorrerà anche essere proprietari del file o
650 proprietari della directory (o root, per cui nessuna delle restrizioni è
653 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
654 della nome dalla directory e l'incremento/decremento del numero di riferimenti
655 nell'inode deve essere una operazione atomica (cioè non interrompibile da
656 altri) processi, per questo entrambe queste funzioni sono realizzate tramite
657 una singola system call.
659 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
660 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
661 count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
662 questo però si aggiunge una altra condizione, e cioè che non ci siano processi
663 che abbiano detto file aperto. Come accennato questa proprietà viene spesso
664 usata per essere sicuri di non lasciare file temporanei su disco in caso di
665 crash dei programmi; la tecnica è quella di aprire il file e chiamare
666 \texttt{unlink} subito dopo.
668 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
669 \label{sec:filedir_cre_canc}
671 Al contrario di quanto avviene con altri unix in Linux non è possibile usare
672 \texttt{unlink} sulle directory, per cancellare una directory si può usare la
673 funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
674 funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
675 per cancellare un file o una directory (e funziona anche per i sistemi che non
676 supportano i link diretti), che per i file è identica alla \texttt{unlink} e
677 per le directory è identica alla \texttt{rmdir}:
679 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
680 Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e
681 \texttt{rmdir} per le directory.
683 La funzione restituisce zero in caso di successo e -1 per un errore, nel
684 qual caso il file non viene toccato. Per i codici di errori vedi quanto
685 riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}.
688 Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il
689 vantaggio nell'uso di questa funzione al posto della chiamata successiva di
690 \texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in
691 questo modo non c'è la possibilità che un processo che cerchi di accedere al
692 nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante.
694 \begin{prototype}{stdio.h}
695 {int rename(const char *oldpath, const char *newpath)}
696 Rinomina un file, spostandolo fra directory diverse quando richiesto.
698 La funzione restituisce zero in caso di successo e -1 per un errore, nel
699 qual caso il file non viene toccato. La variabile \texttt{errno} viene
700 settata secondo i seguenti codici di errore:
702 \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre
703 \texttt{oldpath} non è una directory.
704 \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
706 \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e
708 \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da
709 parte di qualche processo (come directory di lavoro o come root) o del
710 sistema (come mount point).
711 \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di
712 \texttt{oldpath} o più in generale si è cercato di creare una directory
713 come sottodirectory di se stessa.
714 \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link
715 consentiti o è una directory e la directory che contiene \texttt{newpath}
716 ha già il massimo numero di link.
717 \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory
718 o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una
720 \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello
721 spazio di indirizzi del processo.
722 \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
723 cui si vuole creare il nuovo link o una delle directory del pathname non
724 consente la ricerca (permesso di esecuzione).
725 \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o
726 \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non
727 consentono rispettivamente la cancellazione e la creazione del file, o il
728 filesystem non supporta i link.
729 \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo.
730 \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
732 \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
733 completare l'operazione.
734 \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura.
735 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
737 \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la
742 \subsection{I link simbolici}
743 \label{sec:filedir_sym_link}
745 Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
746 funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
747 in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
748 tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una
751 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
752 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
753 come avviene in altri sistemi operativi, dei file che contengono il
754 semplicemente il riferimento ad un altro file (o directory). In questo modo è
755 possibile effettuare link anche attraverso filesystem diversi e a directory, e
756 pure a file che non esistono ancora.
758 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
759 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
760 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
761 lettura del contenuto del medesimo e l'applicazione della funzione al file
762 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
763 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
764 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
765 alle informazioni del link invece che a quelle del file a cui esso fa
768 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
769 dichiarate nell'header file \texttt{unistd.h}.
771 \begin{prototype}{unistd.h}
772 {int symlink(const char * oldname, const char * newname)}
773 Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
774 nome \texttt{newname}.
776 La funzione restituisce zero in caso di successo e -1 per un errore, in caso
777 di errore. La variabile \texttt{errno} viene settata secondo i codici di
778 errore standard di accesso ai files (trattati in dettaglio in
779 \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
781 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
783 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
784 su un filesystem montato readonly.
785 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
786 link è piena e non c'è ulteriore spazio disponibile.
787 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
788 \texttt{oldname} o di \texttt{newname}.
792 Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare
793 un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
794 questa funzione è la:
796 \begin{prototype}{unistd.h}
797 {int readlink(const char * path, char * buff, size\_t size)}
798 Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer
799 \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
800 carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
801 piccolo per contenerla.
803 La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
804 -1 per un errore, in caso di errore. La variabile \texttt{errno} viene
805 settata secondo i codici di errore:
807 \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
809 \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
810 su un filesystem montato readonly.
811 \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
812 link è piena e non c'è ulteriore spazio disponibile.
813 \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
814 \texttt{oldname} o di \texttt{newname}.