Aggiornamenti + alcune sockopt di IP
[gapil.git] / filedir.tex
1 %% filedir.tex
2 %%
3 %% Copyright (C) 2000-2018 Simone Piccardi.  Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
9 %% License".
10 %%
11
12 \chapter{La gestione di file e directory}
13 \label{cha:files_and_dirs}
14
15 In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
16 file e directory, iniziando da un approfondimento dell'architettura del
17 sistema illustrata a grandi linee in sez.~\ref{sec:file_arch_overview} ed
18 illustrando le principali caratteristiche di un filesystem e le interfacce
19 che consentono di controllarne il montaggio e lo smontaggio. 
20
21 Esamineremo poi le funzioni di libreria che si usano per copiare, spostare e
22 cambiare i nomi di file e directory e l'interfaccia che permette la
23 manipolazione dei loro attributi. Tratteremo inoltre la struttura di base del
24 sistema delle protezioni e del controllo dell'accesso ai file e le successive
25 estensioni (\textit{Extended Attributes}, ACL, quote disco,
26 \textit{capabilities}). Tutto quello che riguarda invece la gestione dell'I/O
27 sui file è lasciato al capitolo successivo.
28
29
30
31 \section{L'architettura della gestione dei file}
32 \label{sec:file_arch_func}
33
34 In questa sezione tratteremo con maggiori dettagli rispetto a quanto visto in
35 sez.~\ref{sec:file_arch_overview} il \textit{Virtual File System} di Linux e
36 come il kernel può gestire diversi tipi di filesystem, descrivendo prima le
37 caratteristiche generali di un filesystem di un sistema unix-like, per poi
38 fare una panoramica sul filesystem più usato con Linux, l'\acr{ext2} ed i suoi
39 successori.
40
41
42 \subsection{Il funzionamento del \textit{Virtual File System} di Linux}
43 \label{sec:file_vfs_work}
44
45 % NOTE articolo interessante:
46 % http://www.ibm.com/developerworks/linux/library/l-virtual-filesystem-switch/index.html?ca=dgr-lnxw97Linux-VFSdth-LXdW&S_TACT=105AGX59&S_CMP=GRlnxw97
47
48 \itindbeg{Virtual~File~System~(VFS)}
49
50 Come illustrato brevemente in sez.~\ref{sec:file_arch_overview} in Linux il
51 concetto di \textit{everything is a file} è stato implementato attraverso il
52 \textit{Virtual File System}, la cui struttura generale è illustrata in
53 fig.~\ref{fig:file_VFS_scheme}.  Il VFS definisce un insieme di funzioni che
54 tutti i filesystem devono implementare per l'accesso ai file che contengono e
55 l'interfaccia che consente di eseguire l'I/O sui file, che questi siano di
56 dati o dispositivi. 
57
58 \itindbeg{inode}
59
60 L'interfaccia fornita dal VFS comprende in sostanza tutte le funzioni che
61 riguardano i file, le operazioni implementate dal VFS sono realizzate con una
62 astrazione che prevede quattro tipi di oggetti strettamente correlati: i
63 filesystem, le \textit{dentry}, gli \textit{inode} ed i file. A questi oggetti
64 corrispondono una serie di apposite strutture definite dal kernel che
65 contengono come campi le funzioni di gestione e realizzano l'infrastruttura
66 del VFS. L'interfaccia è molto complessa, ne faremo pertanto una trattazione
67 estremamente semplificata che consenta di comprenderne i principi
68 di funzionamento.
69
70 Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
71 filesystem supportato, quando si vuole inserire il supporto di un nuovo
72 filesystem tutto quello che occorre è chiamare la funzione
73 \code{register\_filesystem} passando come argomento la struttura
74 \kstruct{file\_system\_type} (la cui definizione è riportata in
75 fig.~\ref{fig:kstruct_file_system_type}) relativa a quel filesystem. Questa
76 verrà inserita nella tabella, ed il nuovo filesystem comparirà in
77 \procfile{/proc/filesystems}.
78
79 \begin{figure}[!htb]
80   \footnotesize \centering
81   \begin{minipage}[c]{0.80\textwidth}
82     \includestruct{listati/file_system_type.h}
83   \end{minipage}
84   \normalsize 
85   \caption{Estratto della struttura \kstructd{file\_system\_type} usata dal
86     VFS (da \texttt{include/linux/fs.h}).}
87   \label{fig:kstruct_file_system_type}
88 \end{figure}
89
90 La struttura \kstruct{file\_system\_type}, oltre ad una serie di dati interni,
91 come il nome del tipo di filesystem nel campo \var{name},\footnote{quello che
92   viene riportato in \procfile{/proc/filesystems} e che viene usato come
93   valore del parametro dell'opzione \texttt{-t} del comando \texttt{mount} che
94   indica il tipo di filesystem.}  contiene i riferimenti alle funzioni di base
95 che consentono l'utilizzo di quel filesystem. In particolare la funzione
96 \code{mount} del quarto campo è quella che verrà invocata tutte le volte che
97 si dovrà effettuare il montaggio di un filesystem di quel tipo. Per ogni nuovo
98 filesystem si dovrà allocare una di queste strutture ed inizializzare i
99 relativi campi con i dati specifici di quel filesystem, ed in particolare si
100 dovrà creare anche la relativa versione della funzione \code{mount}.
101
102 \itindbeg{pathname}
103 \itindbeg{pathname~resolution}
104
105 Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
106 restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
107   entry}. Le \textit{dentry} sono gli oggetti che il kernel usa per eseguire
108 la \textit{pathname resolution}, ciascuna di esse corrisponde ad un
109 \textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
110 vedremo a breve è l'oggetto usato dal kernel per identificare un
111 file.\footnote{in questo caso si parla di file come di un qualunque oggetto
112   generico che sta sul filesystem e non dell'oggetto file del VFS cui
113   accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione
114 \code{mount} sarà inserita in corrispondenza al \textit{pathname} della
115 directory in cui il filesystem è stato montato.
116
117 % NOTA: struct dentry è dichiarata in include/linux/dcache.h
118
119 Le \textit{dentry} sono oggetti del VFS che vivono esclusivamente in memoria,
120 nella cosiddetta \textit{directory entry cache} (spesso chiamata in breve
121 \textit{dcache}). Ogni volta che una \textit{system call} specifica un
122 \textit{pathname} viene effettuata una ricerca nella \textit{dcache} per
123 ottenere immediatamente la \textit{dentry} corrispondente,\footnote{il buon
124   funzionamento della \textit{dcache} è in effetti di una delle parti più
125   critiche per le prestazioni del sistema.} che a sua volta ci darà, tramite
126 l'\textit{inode}, il riferimento al file.
127
128 Dato che normalmente non è possibile mantenere nella \textit{dcache} le
129 informazioni relative a tutto l'albero dei file la procedura della
130 \textit{pathname resolution} richiede un meccanismo con cui riempire gli
131 eventuali vuoti. Il meccanismo prevede che tutte le volte che si arriva ad una
132 \textit{dentry} mancante venga invocata la funzione \texttt{lookup}
133 dell'\textit{inode} associato alla \textit{dentry} precedente nella
134 risoluzione del \textit{pathname},\footnote{che a questo punto è una
135   directory, per cui si può cercare al suo interno il nome di un file.} il cui
136 scopo è risolvere il nome mancante e fornire la sua \textit{dentry} che a
137 questo punto verrà inserita nella cache.
138
139 Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount}
140 (vedi sez.~\ref{sec:filesystem_mounting}) della corrispondente
141 \kstruct{file\_system\_type} inserisce la \textit{dentry} iniziale nel
142 \textit{mount point} dello stesso, si avrà comunque un punto di
143 partenza. Inoltre essendo questa \textit{dentry} relativa a quel tipo di
144 filesystem essa farà riferimento ad un \textit{inode} di quel filesystem, e
145 come vedremo questo farà sì che venga eseguita una \texttt{lookup} adatta per
146 effettuare la risoluzione dei nomi per quel filesystem.
147
148 \itindend{pathname}
149 \itindend{pathname~resolution}
150
151 % Un secondo effetto della chiamata funzione \texttt{mount} di
152 % \kstruct{file\_system\_type} è quello di allocare una struttura
153 % \kstruct{super\_block} per ciascuna istanza montata, che contiene le
154 % informazioni generali di un qualunque filesystem montato, come le opzioni di
155 % montaggio, le dimensioni dei blocchi, quando il filesystem è stato montato
156 % ecc. Fra queste però viene pure inserta, nel campo \var{s\_op}, una ulteriore
157 % struttura \kstruct{super\_operations}, il cui contenuto sono i puntatori
158 % alle funzioni di gestione di un filesystem, anche inizializzata in modo da
159 % utilizzare le versioni specifiche di quel filesystem.
160
161 L'oggetto più importante per il funzionamento del VFS è probabilmente
162 l'\textit{inode}, ma con questo nome si può fare riferimento a due cose
163 diverse.  La prima è la struttura su disco (su cui torneremo anche in
164 sez.~\ref{sec:file_filesystem}) che fa parte della organizzazione dei dati
165 realizzata dal filesystem e che contiene le informazioni relative alle
166 proprietà (i cosiddetti \textsl{metadati}) di ogni oggetto presente su di esso
167 (si intende al solito uno qualunque dei tipi di file di
168 tab.~\ref{tab:file_file_types}).
169
170 La seconda è la corrispondente struttura \kstruct{inode}, della cui
171 definizione si è riportato un estratto in
172 fig.~\ref{fig:kstruct_inode}.\footnote{l'estratto fa riferimento alla versione
173   del kernel 2.6.37.} Questa struttura viene mantenuta in memoria ed è a
174 questa che facevamo riferimento quando parlavamo dell'\textit{inode} associato
175 a ciascuna \textit{dentry}. Nella struttura in memoria sono presenti gli
176 stessi \textsl{metadati} memorizzati su disco, che vengono letti quando questa
177 struttura viene allocata e trascritti all'indietro se modificati.
178
179 \begin{figure}[!htb]
180   \footnotesize \centering
181   \begin{minipage}[c]{0.8\textwidth}
182     \includestruct{listati/inode.h}
183   \end{minipage}
184   \normalsize 
185   \caption{Estratto della struttura \kstructd{inode} del kernel (da
186     \texttt{include/linux/fs.h}).}
187   \label{fig:kstruct_inode}
188 \end{figure}
189
190 Il fatto che la struttura \kstruct{inode} sia mantenuta in memoria,
191 direttamente associata ad una \textit{dentry}, rende sostanzialmente immediate
192 le operazioni che devono semplicemente effettuare un accesso ai dati in essa
193 contenuti: è così ad esempio che viene realizzata la \textit{system call}
194 \func{stat} che vedremo in sez.~\ref{sec:file_stat}. Rispetto ai dati salvati
195 sul disco questa struttura contiene però anche quanto necessario alla
196 implementazione del VFS, ed in particolare è importante il campo \var{i\_op}
197 che, come illustrato in fig.~\ref{fig:kstruct_inode}, contiene il puntatore ad
198 una struttura di tipo \kstruct{inode\_operation}, la cui definizione si può
199 trovare nel file \texttt{include/kernel/fs.h} dei sorgenti del kernel.
200
201 Questa struttura non è altro che una tabella di funzioni, ogni suo membro cioè
202 è un puntatore ad una funzione e, come suggerisce il nome della struttura
203 stessa, queste funzioni sono quelle che definiscono le operazioni che il VFS
204 può compiere su un \textit{inode}. Si sono riportate in
205 tab.~\ref{tab:file_inode_operations} le più rilevanti.
206
207 \begin{table}[htb]
208   \centering
209   \footnotesize
210   \begin{tabular}[c]{|l|l|}
211     \hline
212     \textbf{Funzione} & \textbf{Operazione} \\
213     \hline
214     \hline
215     \textsl{\code{create}} & Chiamata per creare un nuovo file (vedi
216                              sez.~\ref{sec:file_open_close}).\\ 
217     \textsl{\code{link}}   & Crea un \textit{hard link} (vedi
218                              sez.~\ref{sec:link_symlink_rename}).\\
219     \textsl{\code{unlink}} & Cancella un \textit{hard link} (vedi
220                              sez.~\ref{sec:link_symlink_rename}).\\
221     \textsl{\code{symlink}}& Crea un collegamento simbolico (vedi
222                              sez.~\ref{sec:link_symlink_rename}).\\
223     \textsl{\code{mkdir}}  & Crea una directory (vedi
224                              sez.~\ref{sec:file_dir_creat_rem}).\\
225     \textsl{\code{rmdir}}  & Rimuove una directory (vedi
226                              sez.~\ref{sec:file_dir_creat_rem}).\\
227     \textsl{\code{mknod}}  & Crea un file speciale (vedi
228                              sez.~\ref{sec:file_mknod}).\\
229     \textsl{\code{rename}} & Cambia il nome di un file (vedi
230                              sez.~\ref{sec:link_symlink_rename}).\\
231     \textsl{\code{lookup}}&  Risolve il nome di un file.\\
232     \hline
233   \end{tabular}
234   \caption{Le principali operazioni sugli \textit{inode} definite tramite
235     \kstructd{inode\_operation}.} 
236   \label{tab:file_inode_operations}
237 \end{table}
238
239 Possiamo notare come molte di queste funzioni abbiano nomi sostanzialmente
240 identici alle varie \textit{system call} con le quali si gestiscono file e
241 directory, che tratteremo nel resto del capitolo. Quello che succede è che
242 tutte le volte che deve essere eseguita una \textit{system call}, o una
243 qualunque altra operazione su un \textit{inode} (come \texttt{lookup}) il VFS
244 andrà ad utilizzare la funzione corrispondente attraverso il puntatore
245 \var{i\_op}.
246
247 Sarà allora sufficiente che nella realizzazione di un filesystem si crei una
248 implementazione di queste funzioni per quel filesystem e si allochi una
249 opportuna istanza di \kstruct{inode\_operation} contenente i puntatori a dette
250 funzioni. A quel punto le strutture \kstruct{inode} usate per gli oggetti di
251 quel filesystem otterranno il puntatore alla relativa istanza di
252 \kstruct{inode\_operation} e verranno automaticamente usate le funzioni
253 corrette.
254
255 Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la
256 funzione \texttt{open} che invece è citata in
257 tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
258   invocata dato che nella struttura \kstruct{inode} è presente anche il
259   puntatore \var{i\_fop} alla struttura \kstruct{file\_operation} che fornisce
260   detta funzione.} Questo avviene perché su Linux l'apertura di un file
261 richiede comunque un'altra operazione che mette in gioco l'omonimo oggetto del
262 VFS: l'allocazione di una struttura di tipo \kstruct{file} che viene associata
263 ad ogni file aperto nel sistema.  I motivi per cui viene usata una struttura a
264 parte sono diversi, anzitutto, come illustrato in sez.~\ref{sec:file_fd},
265 questa è necessaria per le operazioni eseguite dai processi con l'interfaccia
266 dei file descriptor. Ogni processo infatti mantiene il riferimento ad una
267 struttura \kstruct{file} per ogni file che ha aperto, ed è tramite essa che
268 esegue le operazioni di I/O. Inoltre il kernel mantiene un elenco di tutti i
269 file aperti nella \textit{file table} (torneremo su questo in
270 sez.~\ref{sec:file_fd}).
271
272 Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad
273 oggetti posti all'interno di un filesystem e vi si applicano quindi le
274 funzioni fornite nell'implementazione di quest'ultimo, quando si apre un file
275 questo può essere anche un file di dispositivo, ed in questo caso il VFS
276 invece di usare le operazioni fornite dal filesystem (come farebbe per un file
277 di dati) dovrà invece ricorrere a quelle fornite dal driver del dispositivo.
278
279 \itindend{inode}
280
281 \begin{figure}[!htb]
282   \footnotesize \centering
283   \begin{minipage}[c]{0.8\textwidth}
284     \includestruct{listati/file.h}
285   \end{minipage}
286   \normalsize 
287   \caption{Estratto della struttura \kstructd{file} del kernel (da
288     \texttt{include/linux/fs.h}).}
289   \label{fig:kstruct_file}
290 \end{figure}
291
292 Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
293 \kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
294 dei file descriptor il cui significato emergerà più avanti, il puntatore
295 \var{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga per
296 i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
297 fornite dal VFS per i file. Si sono riportate in
298 tab.~\ref{tab:file_file_operations} le più significative.
299
300 \begin{table}[htb]
301   \centering
302   \footnotesize
303   \begin{tabular}[c]{|l|p{8cm}|}
304     \hline
305     \textbf{Funzione} & \textbf{Operazione} \\
306     \hline
307     \hline
308     \textsl{\code{open}}   & Apre il file (vedi
309                              sez.~\ref{sec:file_open_close}).\\ 
310     \textsl{\code{read}}   & Legge dal file (vedi sez.~\ref{sec:file_read}).\\
311     \textsl{\code{write}}  & Scrive sul file (vedi 
312                              sez.~\ref{sec:file_write}).\\
313     \textsl{\code{llseek}} & Sposta la posizione corrente sul file (vedi
314                              sez.~\ref{sec:file_lseek}).\\
315     \textsl{\code{ioctl}}  & Accede alle operazioni di controllo 
316                              (vedi sez.~\ref{sec:file_fcntl_ioctl}).\\
317     \textsl{\code{readdir}}& Legge il contenuto di una directory (vedi 
318                              sez.~\ref{sec:file_dir_read}).\\
319     \textsl{\code{poll}}   & Usata nell'I/O multiplexing (vedi
320                              sez.~\ref{sec:file_multiplexing}).\\
321     \textsl{\code{mmap}}   & Mappa il file in memoria (vedi 
322                              sez.~\ref{sec:file_memory_map}).\\
323     \textsl{\code{release}}& Chiamata quando l'ultimo riferimento a un file 
324                              aperto è chiuso.\\
325     \textsl{\code{fsync}}  & Sincronizza il contenuto del file (vedi
326                              sez.~\ref{sec:file_sync}).\\
327     \textsl{\code{fasync}} & Abilita l'I/O asincrono (vedi
328                              sez.~\ref{sec:file_asyncronous_io}) sul file.\\
329     \hline
330   \end{tabular}
331   \caption{Operazioni sui file definite tramite \kstructd{file\_operation}.}
332   \label{tab:file_file_operations}
333 \end{table}
334
335 Anche in questo caso tutte le volte che deve essere eseguita una
336 \textit{system call} o una qualunque altra operazione sul file il VFS andrà ad
337 utilizzare la funzione corrispondente attraverso il puntatore
338 \var{f\_op}. Dato che è cura del VFS quando crea la struttura all'apertura del
339 file assegnare a \var{f\_op} il puntatore alla versione di
340 \kstruct{file\_operation} corretta per quel file, sarà possibile scrivere allo
341 stesso modo sulla porta seriale come su un normale file di dati, e lavorare
342 sui file allo stesso modo indipendentemente dal filesystem.
343
344 Il VFS realizza la quasi totalità delle operazioni relative ai file grazie
345 alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e
346 \kstruct{file\_operation}.  Ovviamente non è detto che tutte le operazioni
347 possibili siano poi disponibili in tutti i casi, ad esempio \code{llseek} non
348 sarà presente per un dispositivo come la porta seriale o per una
349 \textit{fifo}, mentre sui file del filesystem \texttt{vfat} non saranno
350 disponibili i permessi, ma resta il fatto che grazie al VFS le \textit{system
351   call} per le operazioni sui file possono restare sempre le stesse nonostante
352 le enormi differenze che possono esserci negli oggetti a cui si applicano.
353  
354
355 \itindend{Virtual~File~System~(VFS)}
356
357 % NOTE: documentazione interessante:
358 %       * sorgenti del kernel: Documentation/filesystems/vfs.txt
359 %       * http://thecoffeedesk.com/geocities/rkfs.html
360 %       * http://www.linux.it/~rubini/docs/vfs/vfs.html
361
362
363
364 \subsection{Il funzionamento di un filesystem Unix}
365 \label{sec:file_filesystem}
366
367 Come già accennato in sez.~\ref{sec:file_arch_overview} Linux (ed ogni sistema
368 unix-like) organizza i dati che tiene su disco attraverso l'uso di un
369 filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
370 quella di poter supportare, grazie al VFS, una enorme quantità di filesystem
371 diversi, ognuno dei quali avrà una sua particolare struttura e funzionalità
372 proprie.  Per questo non entreremo nei dettagli di un filesystem specifico, ma
373 daremo una descrizione a grandi linee che si adatta alle caratteristiche
374 comuni di qualunque filesystem di un sistema unix-like.
375
376 \itindbeg{superblock}
377
378 Una possibile strutturazione dell'informazione su un disco è riportata in
379 fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre
380 partizioni. In essa per semplicità si è fatto riferimento alla struttura del
381 filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
382   group}.  All'interno di ciascun \textit{block group} viene anzitutto
383 replicato il cosiddetto \textit{superblock}, (la struttura che contiene
384 l'indice iniziale del filesystem e che consente di accedere a tutti i dati
385 sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
386 per accedere agli stessi.  Sulle caratteristiche di \acr{ext2} e derivati
387 torneremo in sez.~\ref{sec:file_ext2}.
388
389 \itindend{superblock}
390 \itindbeg{inode}
391
392 È comunque caratteristica comune di tutti i filesystem per Unix,
393 indipendentemente da come poi viene strutturata nei dettagli questa
394 informazione, prevedere la presenza di due tipi di risorse: gli
395 \textit{inode}, cui abbiamo già accennato in sez.~\ref{sec:file_vfs_work}, che
396 sono le strutture che identificano i singoli oggetti sul filesystem, e i
397 blocchi, che invece attengono allo spazio disco che viene messo a disposizione
398 per i dati in essi contenuti.
399
400 \begin{figure}[!htb]
401   \centering
402   \includegraphics[width=11cm]{img/disk_struct}
403   \caption{Organizzazione dello spazio su un disco in partizioni e
404   filesystem.}
405   \label{fig:file_disk_filesys}
406 \end{figure}
407
408 Se si va ad esaminare con maggiore dettaglio la strutturazione
409 dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
410 dettagli relativi al funzionamento del filesystem stesso come la
411 strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
412 gestione possiamo esemplificare la situazione con uno schema come quello
413 esposto in fig.~\ref{fig:file_filesys_detail}.
414
415 \begin{figure}[!htb]
416   \centering
417   \includegraphics[width=11cm]{img/filesys_struct}
418   \caption{Strutturazione dei dati all'interno di un filesystem.}
419   \label{fig:file_filesys_detail}
420 \end{figure}
421
422 Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle
423 caratteristiche di base di un filesystem, che restano le stesse anche su
424 filesystem la cui organizzazione dei dati è totalmente diversa da quella
425 illustrata, e sulle quali è bene porre attenzione visto che sono fondamentali
426 per capire il funzionamento delle funzioni che manipolano i file e le
427 directory che tratteremo nel prosieguo del capitolo. In particolare è
428 opportuno tenere sempre presente che:
429
430
431 \begin{enumerate}
432   
433 \item L'\textit{inode} contiene i cosiddetti \textsl{metadati}, vale dire le
434   informazioni riguardanti le proprietà del file come oggetto del filesystem:
435   il tipo di file, i permessi di accesso, le dimensioni, i puntatori ai
436   blocchi fisici che contengono i dati e così via. Le informazioni che la
437   funzione \func{stat} (vedi sez.~\ref{sec:file_stat}) fornisce provengono
438   dall'\textit{inode}.  Dentro una directory si troverà solo il nome del file
439   e il numero dell'\textit{inode} ad esso associato; il nome non è una
440   proprietà del file e non viene mantenuto nell'\textit{inode}. Da da qui in
441   poi chiameremo il nome del file contenuto in una directory
442   ``\textsl{voce}'', come traduzione della nomenclatura inglese
443   \textit{directory entry} che non useremo per evitare confusione con le
444   \textit{dentry} del kernel viste in sez.~\ref{sec:file_vfs_work}.
445   
446 \item Come mostrato in fig.~\ref{fig:file_filesys_detail} per i file
447   \texttt{macro.tex} e \texttt{gapil\_macro.tex}, ci possono avere più voci
448   che fanno riferimento allo stesso \textit{inode}. Fra le proprietà di un
449   file mantenute nell'\textit{inode} c'è anche il contatore con il numero di
450   riferimenti che sono stati fatti ad esso, il cosiddetto \textit{link
451     count}.\footnote{mantenuto anche nel campo \var{i\_nlink} della struttura
452     \kstruct{inode} di fig.~\ref{fig:kstruct_inode}.}  Solo quando questo
453   contatore si annulla i dati del file possono essere effettivamente rimossi
454   dal disco. Per questo la funzione per cancellare un file si chiama
455   \func{unlink} (vedi sez.~\ref{sec:link_symlink_rename}), ed in realtà non
456   cancella affatto i dati del file, ma si limita ad eliminare la relativa voce
457   da una directory e decrementare il numero di riferimenti
458   nell'\textit{inode}.
459   
460 \item All'interno di ogni filesystem ogni \textit{inode} è identificato da un
461   numero univoco. Il numero di \textit{inode} associato ad una voce in una
462   directory si riferisce ad questo numero e non ci può essere una directory
463   che contiene riferimenti ad \textit{inode} relativi ad altri filesystem.
464   Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una
465   nuova voce per un file esistente con la funzione \func{link} (vedi
466   sez.~\ref{sec:link_symlink_rename}), a operare su file nel filesystem
467   corrente.
468   
469 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
470   del file non viene spostato fisicamente, viene semplicemente creata una
471   nuova voce per l'\textit{inode} in questione e rimossa la precedente, questa
472   è la modalità in cui opera normalmente il comando \cmd{mv} attraverso la
473   funzione \func{rename} (vedi sez.~\ref{sec:link_symlink_rename}). Questa
474   operazione non modifica minimamente neanche l'\textit{inode} del file, dato
475   che non si opera sul file ma sulla directory che lo contiene.
476
477 \item Gli \textit{inode} dei file, che contengono i \textsl{metadati}, ed i
478   blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
479   in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
480   possibile esaurire sia lo spazio disco (il caso più comune) che lo spazio
481   per gli \textit{inode}. Nel primo caso non sarà possibile allocare ulteriore
482   spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
483   creare nuovi file, ma si potranno estendere quelli che ci
484   sono.\footnote{questo comportamento non è generale, alcuni filesystem
485     evoluti possono evitare il problema dell'esaurimento degli \textit{inode}
486     riallocando lo spazio disco libero per i blocchi.}
487
488 \end{enumerate}
489
490 \begin{figure}[!htb]
491   \centering 
492   \includegraphics[width=12cm]{img/dir_links}
493   \caption{Organizzazione dei \textit{link} per le directory.}
494   \label{fig:file_dirs_link}
495 \end{figure}
496
497 Infine tenga presente che, essendo file pure loro, il numero di riferimenti
498 esiste anche per le directory. Per questo se a partire dalla situazione
499 mostrata in fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory
500 \file{img} nella directory \file{gapil}, avremo una situazione come quella
501 illustrata in fig.~\ref{fig:file_dirs_link}.
502
503 La nuova directory avrà un numero di riferimenti pari a due, in quanto è
504 referenziata dalla directory da cui si era partiti (in cui è inserita la nuova
505 voce che fa riferimento a \texttt{img}) e dalla voce interna ``\texttt{.}''
506 che è presente in ogni directory.  Questo è il valore che si troverà sempre
507 per ogni directory che non contenga a sua volta altre directory. Al contempo,
508 la directory da cui si era partiti avrà un numero di riferimenti di almeno
509 tre, in quanto adesso sarà referenziata anche dalla voce ``\texttt{..}'' di
510 \texttt{img}. L'aggiunta di una sottodirectory fa cioè crescere di uno il
511 \textit{link count} della directory genitrice.
512
513 \itindend{inode}
514
515
516 \subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori}
517 \label{sec:file_ext2}
518
519 Benché non esista ``il'' filesystem di Linux, dato che esiste un supporto
520 nativo di diversi filesystem che sono in uso da anni, quello che gli avvicina
521 di più è la famiglia di filesystem evolutasi a partire dal \textit{second
522   extended filesystem}, o \acr{ext2}. Il filesystem \acr{ext2} ha subito un
523 grande sviluppo e diverse evoluzioni, fra cui l'aggiunta del
524 \textit{journaling} con il passaggio ad \acr{ext3}, che probabilmente è ancora
525 il filesystem più diffuso, ed una serie di ulteriori miglioramenti con il
526 successivo \acr{ext4}, che sta iniziando a sostituirlo gradualmente. In futuro
527 è previsto che questo debba essere sostituito da un filesystem completamente
528 diverso, \acr{btrfs}, che dovrebbe diventare il filesystem standard di Linux,
529 ma questo al momento è ancora in fase di sviluppo.\footnote{si fa riferimento
530   al momento dell'ultima revisione di di questo paragrafo, l'inizio del 2012.}
531
532 Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
533 dalle prime versioni del kernel e supporta tutte le caratteristiche di un
534 filesystem standard Unix: è in grado di gestire nomi di file lunghi (256
535 caratteri, estensibili a 1012) e supporta una dimensione massima dei file fino
536 a 4~Tb. I successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di
537 questo filesystem, e sia pure con molti miglioramenti ed estensioni
538 significative ne mantengono le caratteristiche fondamentali.
539
540 Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
541 non sono presenti su un classico filesystem di tipo Unix; le principali sono
542 le seguenti:
543 \begin{itemize}
544 \item gli attributi estesi (vedi sez.~\ref{sec:file_xattr}) che consentono di
545   estendere le informazioni salvabili come metadati e le ACL (vedi
546   sez.~\ref{sec:file_ACL}) che consentono di estendere il modello tradizionale
547   dei permessi sui file.
548 \item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
549   montaggio. La semantica BSD comporta che i file in una directory sono creati
550   con lo stesso identificatore di gruppo della directory che li contiene. La
551   semantica SVr4 comporta che i file vengono creati con l'identificatore del
552   gruppo primario del processo, eccetto il caso in cui la directory ha il bit
553   di \acr{sgid} impostato (per una descrizione dettagliata del significato di
554   questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
555   file e subdirectory ereditano sia il \ids{GID} che lo \acr{sgid}.
556 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
557   in fase di creazione, a seconda delle sue esigenze: blocchi più grandi
558   permettono un accesso più veloce, ma sprecano più spazio disco.
559 \item il filesystem implementa collegamenti simbolici veloci, in cui il nome
560   del file non è salvato su un blocco, ma tenuto all'interno
561   dell'\textit{inode} (evitando letture multiple e spreco di spazio), non
562   tutti i nomi però possono essere gestiti così per limiti di spazio (il
563   limite è 60 caratteri).
564 \item vengono supportati i cosiddetti \textit{file attributes} (vedi
565   sez.~\ref{sec:file_perm_overview}) che attivano comportamenti specifici per
566   i file su cui vengono attivati come marcarli come immutabili (che possono
567   cioè essere soltanto letti) per la protezione di file di configurazione
568   sensibili, o come \textit{append-only} (che possono essere aperti in
569   scrittura solo per aggiungere dati) per la protezione dei file di log.
570 \end{itemize}
571
572 La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
573 filesystem è composto da un insieme di blocchi, la struttura generale è quella
574 riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
575 in gruppi di blocchi.
576
577 Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
578 filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore
579 affidabilità e possibilità di recupero in caso di corruzione del
580 \textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha
581 inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la
582 distanza fra i dati e la tabella degli \textit{inode}.
583
584 \begin{figure}[!htb]
585   \centering
586   \includegraphics[width=9cm]{img/dir_struct}  
587   \caption{Struttura delle directory nel \textit{second extended filesystem}.}
588   \label{fig:file_ext2_dirs}
589 \end{figure}
590
591
592 Le directory sono implementate come una \textit{linked list} con voci di
593 dimensione variabile. Ciascuna voce della lista contiene il numero di
594 \textit{inode}, la sua lunghezza, il nome del file e la sua lunghezza, secondo
595 lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo è possibile
596 implementare nomi per i file anche molto lunghi (fino a 1024 caratteri) senza
597 sprecare spazio disco.
598
599 Con l'introduzione del filesystem \textit{ext3} sono state introdotte diverse
600 modifiche strutturali, la principale di queste è quella che \textit{ext3} è un
601 filesystem \textit{journaled}, è cioè in grado di eseguire una registrazione
602 delle operazioni di scrittura su un giornale (uno speciale file interno) in
603 modo da poter garantire il ripristino della coerenza dei dati del
604 filesystem\footnote{si noti bene che si è parlato di dati \textsl{del}
605   filesystem, non di dati \textsl{nel} filesystem, quello di cui viene
606   garantito un veloce ripristino è relativo ai dati della struttura interna
607   del filesystem, non di eventuali dati contenuti nei file che potrebbero
608   essere stati persi.} in brevissimo tempo in caso di interruzione improvvisa
609 della corrente o di crollo del sistema che abbia causato una interruzione
610 della scrittura dei dati sul disco.
611
612 Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare
613 sia le prestazioni che la semplicità di gestione del filesystem, in
614 particolare per le directory si è passato all'uso di alberi binari con
615 indicizzazione tramite \textit{hash} al posto delle \textit{linked list} che
616 abbiamo illustrato, ottenendo un forte guadagno di prestazioni in caso di
617 directory contenenti un gran numero di file.
618
619 % TODO (bassa priorità) portare a ext3, ext4 e btrfs ed illustrare le
620 % problematiche che si possono incontrare (in particolare quelle relative alla
621 % perdita di contenuti in caso di crash del sistema)
622 % TODO (media priorità) trattare btrfs quando sarà usato come stabile
623
624
625 \subsection{La gestione dell'uso dei filesystem}
626 \label{sec:filesystem_mounting}
627
628 Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file
629 occorre rendere disponibile al sistema il filesystem su cui essi sono
630 memorizzati. L'operazione di attivazione del filesystem è chiamata
631 \textsl{montaggio} e per far questo in Linux si usa la funzione di sistema
632 \funcd{mount}, il cui prototipo è:\footnote{la funzione è una versione
633   specifica di Linux che usa la omonima \textit{system call} e non è
634   portabile.}
635
636 \begin{funcproto}{
637 \fhead{sys/mount.h} 
638 \fdecl{mount(const char *source, const char *target, const char
639   *filesystemtype, \\ 
640 \phantom{mount(}unsigned long mountflags, const void *data)}
641 \fdesc{Monta un filesystem.} 
642 }
643 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
644   caso \var{errno} assumerà uno dei valori:
645   \begin{errlist}
646   \item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
647     componenti del \textit{pathname}, o si è cercato di montare un filesystem
648     disponibile in sola lettura senza aver specificato \const{MS\_RDONLY} o il
649     device \param{source} è su un filesystem montato con l'opzione
650     \const{MS\_NODEV}.
651   \item[\errcode{EBUSY}] \param{source} è già montato, o non può essere
652     rimontato in sola lettura perché ci sono ancora file aperti in scrittura,
653     o non può essere montato su \param{target} perché la directory è ancora in
654     uso.
655   \item[\errcode{EINVAL}] il dispositivo \param{source} presenta un
656     \textit{superblock} non valido, o si è cercato di rimontare un filesystem
657     non ancora montato, o di montarlo senza che \param{target} sia un
658     \textit{mount point} o di spostarlo quando \param{target} non è un
659     \textit{mount point} o è la radice.
660   \item[\errcode{ELOOP}] si è cercato di spostare un \textit{mount point} su
661     una sottodirectory di \param{source} o si sono incontrati troppi
662     collegamenti simbolici nella risoluzione di un nome.
663   \item[\errcode{EMFILE}] in caso di filesystem virtuale, la tabella dei
664     dispositivi fittizi (chiamati \textit{dummy} nella documentazione inglese)
665     è piena.
666   \item[\errcode{ENODEV}] il tipo \param{filesystemtype} non esiste o non è
667     configurato nel kernel.
668   \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
669     \param{source} quando era richiesto.
670   \item[\errcode{ENXIO}] il \textit{major number} del
671     dispositivo \param{source} è sbagliato.
672   \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
673   \end{errlist} 
674   ed inoltre \errval{EFAULT}, \errval{ENOMEM}, \errval{ENAMETOOLONG},
675   \errval{ENOENT}, \errval{ENOTDIR} nel loro significato generico.}
676 \end{funcproto}
677
678 \itindbeg{mount~point}
679
680 La funzione monta sulla directory indicata da \param{target}, detta
681 \textit{mount point}, il filesystem contenuto nel file di dispositivo indicato
682 da \param{source}. In entrambi i casi, come daremo per assunto da qui in
683 avanti tutte le volte che si parla di directory o file nel passaggio di un
684 argomento di una funzione, si intende che questi devono essere indicati con la
685 stringa contenente il loro \textit{pathname}.
686
687 Normalmente un filesystem è contenuto su un disco o una partizione, ma come
688 illustrato in sez.~\ref{sec:file_vfs_work} la struttura del \textit{Virtual
689   File System} è estremamente flessibile e può essere usata anche per oggetti
690 diversi da un disco. Ad esempio usando il \textit{loop device} si può montare
691 un file qualunque (come l'immagine di un CD-ROM o di un floppy) che contiene
692 l'immagine di un filesystem, inoltre alcuni tipi di filesystem, come
693 \texttt{proc} o \texttt{sysfs} sono virtuali e non hanno un supporto che ne
694 contenga i dati, che invece sono generati al volo ad ogni lettura, e passati
695 indietro al kernel ad ogni scrittura.\footnote{costituiscono quindi un
696   meccanismo di comunicazione, attraverso l'ordinaria interfaccia dei file,
697   con il kernel.}
698
699 Il tipo di filesystem che si vuole montare è specificato
700 dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
701 riportate nel file \procfilem{/proc/filesystems} che, come accennato in
702 sez.~\ref{sec:file_vfs_work}, contiene l'elenco dei filesystem supportati dal
703 kernel. Nel caso si sia indicato un filesystem virtuale, che non è associato a
704 nessun file di dispositivo, il contenuto di \param{source} viene ignorato.
705
706 L'argomento \param{data} viene usato per passare le impostazioni relative alle
707 caratteristiche specifiche di ciascun filesystem. Si tratta di una stringa di
708 parole chiave (separate da virgole e senza spazi) che indicano le cosiddette
709 ``\textsl{opzioni}'' del filesystem che devono essere impostate; in genere
710 viene usato direttamente il contenuto del parametro dell'opzione \texttt{-o}
711 del comando \texttt{mount}. I valori utilizzabili dipendono dal tipo di
712 filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della
713 pagina di manuale di questo comando e dei singoli filesystem.
714
715 Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
716 disponibile nella directory specificata come \textit{mount point}, il
717 precedente contenuto di detta directory viene mascherato dal contenuto della
718 directory radice del filesystem montato. Fino ai kernel della serie 2.2.x non
719 era possibile montare un filesystem se un \textit{mount point} era già in uso.
720
721 A partire dal kernel 2.4.x inoltre è divenuto possibile sia spostare
722 atomicamente un \textit{mount point} da una directory ad un'altra, sia montare
723 lo stesso filesystem in diversi \textit{mount point}, sia montare più
724 filesystem sullo stesso \textit{mount point} impilandoli l'uno sull'altro, nel
725 qual caso vale comunque quanto detto in precedenza, e cioè che solo il
726 contenuto dell'ultimo filesystem montato sarà visibile.
727
728 \itindend{mount~point}
729
730 Oltre alle opzioni specifiche di ciascun filesystem, che si passano nella
731 forma della lista di parole chiave indicata con l'argomento \param{data},
732 esistono pure alcune opzioni che si possono applicare in generale, anche se
733 non è detto che tutti i filesystem le supportino, che si specificano tramite
734 l'argomento \param{mountflags}.  L'argomento inoltre può essere utilizzato per
735 modificare il comportamento della funzione \func{mount}, facendole compiere
736 una operazione diversa (ad esempio un rimontaggio, invece che un montaggio).
737
738 In Linux \param{mountflags} deve essere un intero a 32 bit; fino ai kernel
739 della serie 2.2.x i 16 più significativi avevano un valore riservato che
740 doveva essere specificato obbligatoriamente,\footnote{il valore era il
741   \textit{magic number} \code{0xC0ED}, si può usare la costante
742   \constd{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata
743   al \textit{magic number}, mentre per specificarlo si può dare un OR
744   aritmetico con la costante \constd{MS\_MGC\_VAL}.} e si potevano usare solo i
745 16 meno significativi. Oggi invece, con un numero di opzioni superiore, sono
746 utilizzati tutti e 32 i bit, ma qualora nei 16 più significativi sia presente
747 detto valore, che non esprime una combinazione valida, esso viene ignorato. Il
748 valore dell'argomento deve essere espresso come maschera binaria e i vari bit
749 che lo compongono, detti anche \textit{mount flags}, devono essere impostati
750 con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
751
752 \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
753 \itindbeg{bind~mount}
754 \item[\constd{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in cui è
755   possibile montare una directory di un filesystem in un'altra directory,
756   l'opzione è disponibile a partire dai kernel della serie 2.4. In questo caso
757   verranno presi in considerazione solo gli argomenti \param{source}, che
758   stavolta indicherà la directory che si vuole montare e non un file di
759   dispositivo, e \param{target} che indicherà la directory su cui verrà
760   effettuato il \textit{bind mount}. Gli argomenti \param{filesystemtype}
761   e \param{data} vengono ignorati.
762
763   In sostanza quello che avviene è che in corrispondenza del \textit{pathname}
764   indicato da \param{target} viene montato l'\textit{inode} di \param{source},
765   così che la porzione di albero dei file presente sotto \param{source}
766   diventi visibile allo stesso modo sotto \param{target}. Trattandosi
767   esattamente dei dati dello stesso filesystem, ogni modifica fatta in uno
768   qualunque dei due rami di albero sarà visibile nell'altro, visto che
769   entrambi faranno riferimento agli stessi \textit{inode}.
770
771   Dal punto di vista del VFS l'operazione è analoga al montaggio di un
772   filesystem proprio nel fatto che anche in questo caso si inserisce in
773   corrispondenza della \textit{dentry} di \texttt{target} un diverso
774   \textit{inode}, che stavolta, invece di essere quello della radice del
775   filesystem indicato da un file di dispositivo, è quello di una directory già
776   montata.
777
778   Si tenga presente che proprio per questo sotto \param{target} comparirà il
779   contenuto che è presente sotto \param{source} all'interno del filesystem in
780   cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla
781   porzione di albero che sta sotto \param{source} qualora in una
782   sottodirectory di quest'ultima si fosse effettuato un altro montaggio. In
783   tal caso infatti nella porzione di albero sotto \param{source} si troverebbe
784   il contenuto del nuovo filesystem (o di un altro \textit{bind mount}) mentre
785   sotto \param{target} ci sarebbe il contenuto presente nel filesystem
786   originale.\footnote{questo evita anche il problema dei \textit{loop} di
787     fig.~\ref{fig:file_link_loop}, dato che se anche si montasse su
788     \param{target} una directory in cui essa è contenuta, il cerchio non
789     potrebbe chiudersi perché ritornati a \param{target} dentro il
790     \textit{bind mount} vi si troverebbe solo il contenuto originale e non si
791     potrebbe tornare indietro.}
792
793   Fino al kernel 2.6.26 questo flag doveva essere usato da solo, in quanto il
794   \textit{bind mount} continuava ad utilizzare le stesse opzioni del montaggio
795   originale, dal 2.6.26 è stato introdotto il supporto per il cosiddetto
796   \textit{read-only bind mount} e viene onorata la presenza aggiuntiva del
797   flag \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file
798   sotto \param{target} sia effettuabile esclusivamente in sola lettura.
799
800   Il supporto per il \textit{bind mount} consente di superare i limiti
801   presenti per gli \textit{hard link} (di cui parleremo in
802   sez.~\ref{sec:link_symlink_rename}) con la possibilità di fare riferimento
803   alla porzione dell'albero dei file di un filesystem presente a partire da
804   una certa directory, utilizzando una qualunque altra directory, anche se
805   questa sta su un filesystem diverso. Si può così fornire una alternativa
806   all'uso dei collegamenti simbolici (di cui parleremo in
807   sez.~\ref{sec:link_symlink_rename}) che funziona correttamente anche
808   all'intero di un \textit{chroot} (argomento su cui torneremo in
809   sez.~\ref{sec:file_chroot}).  
810
811 \itindend{bind~mount}
812
813 \item[\constd{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
814   directory venga immediatamente registrata su disco in maniera sincrona
815   (introdotta a partire dai kernel della serie 2.6). L'opzione si applica a
816   tutte le directory del filesystem, ma su alcuni filesystem è possibile
817   impostarla a livello di singole directory o per i sottorami di una directory
818   con il comando \cmd{chattr}.\footnote{questo avviene tramite delle opportune
819     \texttt{ioctl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).}
820
821   Questo consente di ridurre al minimo il rischio di perdita dei dati delle
822   directory in caso di crollo improvviso del sistema, al costo di una certa
823   perdita di prestazioni dato che le funzioni di scrittura relative ad
824   operazioni sulle directory non saranno più bufferizzate e si bloccheranno
825   fino all'arrivo dei dati sul disco prima che un programma possa proseguire.
826
827 \item[\constd{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
828   (vedi sez.~\ref{sec:file_mand_locking}) sui file del filesystem. Per poterlo
829   utilizzare effettivamente però esso dovrà essere comunque attivato
830   esplicitamente per i singoli file impostando i permessi come illustrato in
831   sez.~\ref{sec:file_mand_locking}.
832
833 \item[\constd{MS\_MOVE}] Effettua uno del spostamento del \textit{mount point}
834   di un filesystem. La directory del \textit{mount point} originale deve
835   essere indicata nell'argomento \param{source}, e la sua nuova posizione
836   nell'argomento \param{target}. Tutti gli altri argomenti della funzione
837   vengono ignorati.
838
839   Lo spostamento avviene atomicamente, ed il ramo di albero presente
840   sotto \param{source} sarà immediatamente visibile sotto \param{target}. Non
841   esiste cioè nessun momento in cui il filesystem non risulti montato in una o
842   nell'altra directory e pertanto è garantito che la risoluzione di
843   \textit{pathname} relativi all'interno del filesystem non possa fallire.
844
845 \item[\constd{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
846   degli \textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
847   qualunque tipo di file. Dato che l'aggiornamento degli \textit{access time}
848   è una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
849   elevato visto che una qualunque lettura comporta comunque una scrittura su
850   disco,\footnote{e questo ad esempio ha conseguenze molto pesanti nell'uso
851     della batteria sui portatili.} questa opzione consente di disabilitarla
852   completamente. La soluzione può risultare troppo drastica dato che
853   l'informazione viene comunque utilizzata da alcuni programmi, per cui nello
854   sviluppo del kernel sono state introdotte altre opzioni che forniscono
855   soluzioni più appropriate e meno radicali.
856
857 \item[\constd{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
858   di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
859   misura di precauzione per rendere inutile la presenza di eventuali file di
860   dispositivo su filesystem che non dovrebbero contenerne.\footnote{si ricordi
861     che le convenzioni del \textit{Linux Filesystem Hierarchy Standard}
862     richiedono che questi siano mantenuti esclusivamente sotto \texttt{/dev}.}
863
864   Viene utilizzata, assieme a \const{MS\_NOEXEC} e \const{MS\_NOSUID}, per
865   fornire un accesso più controllato a quei filesystem di cui gli utenti hanno
866   il controllo dei contenuti, in particolar modo quelli posti su dispositivi
867   rimuovibili. In questo modo si evitano alla radice possibili situazioni in
868   cui un utente malizioso inserisce su uno di questi filesystem dei file di
869   dispositivo con permessi ``opportunamente'' ampliati che gli consentirebbero
870   di accedere anche a risorse cui non dovrebbe.
871
872 \item[\constd{MS\_NODIRATIME}] Viene disabilitato sul filesystem
873   l'aggiornamento degli \textit{access time} (vedi
874   sez.~\ref{sec:file_file_times}), ma soltanto per le directory. Costituisce
875   una alternativa per \const{MS\_NOATIME}, che elimina l'informazione per le
876   directory, che in pratica che non viene mai utilizzata, mantenendola per i
877   file in cui invece ha un impiego, sia pur limitato.
878
879 \item[\constd{MS\_NOEXEC}] Viene disabilitata sul filesystem l'esecuzione di un
880   qualunque file eseguibile eventualmente presente su di esso. L'opzione viene
881   usata come misura di precauzione per rendere impossibile l'uso di programmi
882   posti su filesystem che non dovrebbero contenerne.
883
884   Anche in questo caso viene utilizzata per fornire un accesso più controllato
885   a quei filesystem di cui gli utenti hanno il controllo dei contenuti. Da
886   questo punto di vista l'opzione è meno importante delle analoghe
887   \const{MS\_NODEV} e \const{MS\_NOSUID} in quanto l'esecuzione di un
888   programma creato dall'utente pone un livello di rischio nettamente
889   inferiore, ed è in genere consentita per i file contenuti nella sua home
890   directory.\footnote{cosa che renderebbe superfluo l'attivazione di questa
891     opzione, il cui uso ha senso solo per ambienti molto controllati in cui si
892     vuole che gli utenti eseguano solo i programmi forniti
893     dall'amministratore.}
894
895 \item[\constd{MS\_NOSUID}] Viene disabilitato sul filesystem l'effetto dei bit
896   dei permessi \acr{suid} e \acr{sgid} (vedi sez.~\ref{sec:file_special_perm})
897   eventualmente presenti sui file in esso contenuti. L'opzione viene usata
898   come misura di precauzione per rendere inefficace l'effetto di questi bit
899   per filesystem in cui non ci dovrebbero essere file dotati di questi
900   permessi.
901
902   Di nuovo viene utilizzata, analogamente a \const{MS\_NOEXEC} e
903   \const{MS\_NODEV}, per fornire un accesso più controllato a quei filesystem
904   di cui gli utenti hanno il controllo dei contenuti. In questo caso si evita
905   che un utente malizioso possa inserire su uno di questi filesystem un
906   eseguibile con il bit \acr{suid} attivo e di proprietà dell'amministratore o
907   di un altro utente, che gli consentirebbe di eseguirlo per conto di
908   quest'ultimo.
909
910 \item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come privato. Si
911   tratta di una delle nuove opzioni (insieme a \const{MS\_SHARED},
912   \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti parte
913   dell'infrastruttura degli \textit{shared subtree} introdotta a partire dal
914   kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}. In
915   questo caso \param{target} dovrà fare riferimento al \textit{mount point}
916   che si intende marcare, e tutti gli altri argomenti verranno ignorati.
917
918   Di default, finché non lo si marca altrimenti con una delle altre opzioni
919   dell'interfaccia come \textit{shared subtree}, ogni \textit{mount point} è
920   privato. Ogni \textit{bind mount} ottenuto da un \textit{mount point} di
921   tipo \textit{private} si comporta come descritto nella trattazione di
922   \const{MS\_BIND}. Si usa questo flag principalmente per revocare gli effetti
923   delle altre opzioni e riportare il comportamento a quello ordinario.
924
925 \item[\constd{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
926   non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le
927   volte che si deve accedere ai contenuti di un filesystem con la certezza che
928   questo non venga modificato (ad esempio per ispezionare un filesystem
929   corrotto). All'avvio di default il kernel monta la radice in questa
930   modalità.
931
932 \item[\constd{MS\_REC}] Applica ricorsivamente a tutti i \textit{mount point}
933   presenti al di sotto del \textit{mount point} indicato gli effetti della
934   opzione degli \textit{shared subtree} associata. Anche questo caso
935   l'argomento \param{target} deve fare riferimento ad un \textit{mount point}
936   e tutti gli altri argomenti sono ignorati, ed il flag deve essere indicato
937   assieme ad una fra \const{MS\_PRIVATE}, \const{MS\_SHARED},
938   \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}.
939
940   % TODO trattare l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
941   % vedi http://lwn.net/Articles/621046/
942
943 \item[\constd{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
944   \textit{access time} sul filesystem soltanto quando questo risulti
945   antecedente il valore corrente del \textit{modification time} o del
946   \textit{change time} (per i tempi dei file si veda
947   sez.~\ref{sec:file_file_times}). L'opzione è disponibile a partire dal
948   kernel 2.6.20, mentre dal 2.6.30 questo è diventato il comportamento di
949   default del sistema, che può essere riportato a quello tradizionale con
950   l'uso di \const{MS\_STRICTATIME}. Sempre dal 2.6.30 il comportamento è stato
951   anche modificato e l'\textit{access time} viene comunque aggiornato se è più
952   vecchio di un giorno.
953
954   L'opzione consente di evitare i problemi di prestazioni relativi
955   all'aggiornamento dell'\textit{access time} senza avere impatti negativi
956   riguardo le funzionalità, il comportamento adottato infatti consente di
957   rendere evidente che vi è stato un accesso dopo la scrittura, ed evitando al
958   contempo ulteriori operazioni su disco negli accessi successivi. In questo
959   modo l'informazione relativa al fatto che un file sia stato letto resta
960   disponibile, ed i programmi che ne fanno uso continuano a funzionare. Con
961   l'introduzione di questo comportamento l'uso delle alternative
962   \const{MS\_NOATIME} e \const{MS\_NODIRATIME} è sostanzialmente inutile.
963
964 \item[\constd{MS\_REMOUNT}] Consente di rimontare un filesystem già montato
965   cambiandone le opzioni di montaggio in maniera atomica. In questo modo si
966   possono modificare le opzioni del filesystem anche se questo è in uso. Gli
967   argomenti \param{source} e \param{target} devono essere gli stessi usati per
968   il montaggio originale, mentre sia \param{data} che \param{mountflags}
969   conterranno le nuove opzioni, \param{filesystemtype} viene ignorato.
970
971   Qualunque opzione specifica del filesystem indicata con \param{data} può
972   essere modificata, mentre con \param{mountflags} possono essere modificate
973   solo alcune opzioni generiche. Con i kernel più recenti queste sono soltanto
974   \const{MS\_MANDLOCK}, \const{MS\_RDONLY} e \const{MS\_SYNCHRONOUS}, prima
975   del kernel 2.6.16 potevano essere modificate anche le ulteriori
976   \const{MS\_NOATIME} e \const{MS\_NODIRATIME}, ed infine prima del kernel
977   2.4.10 anche \const{MS\_NODEV}, \const{MS\_NOEXEC} e \const{MS\_NOSUID}.
978
979 \itindbeg{shared~subtree}
980
981 \item[\constd{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared
982     mount}. Si tratta di una delle nuove opzioni (insieme a
983   \const{MS\_PRIVATE}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
984   parte dell'infrastruttura dei cosiddetti \textit{shared subtree} introdotta
985   a partire dal kernel 2.6.15, che estendono le funzionalità dei \textit{bind
986     mount}.  In questo caso \param{target} dovrà fare riferimento al
987   \textit{mount point} che si intende marcare, e tutti gli altri argomenti
988   verranno ignorati.
989
990   Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
991   effettuati da un \textit{mount point} marcato da essa siano di tipo
992   \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
993   ogni ulteriore operazione di montaggio o smontaggio che avviene su una
994   directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
995   smontaggio effettuate al di sotto di un qualunque \textit{mount point} così
996   marcato verranno ``\textsl{propagate}'' a tutti i \textit{mount point} della
997   stessa condivisione, e la sezione di albero di file vista al di sotto di
998   ciascuno di essi sarà sempre identica.
999
1000 \itindend{shared~subtree}
1001
1002 \item[\constd{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
1003   avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
1004   è presente a partire dal kernel 2.6.17 e sostituisce, utilizzando un nome
1005   non fuorviante, la precedente \const{MS\_VERBOSE}, introdotta nel kernel
1006   2.6.12, che aveva lo stesso effetto.
1007
1008 \item[\constd{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave
1009     mount}. Si tratta di una delle nuove opzioni (insieme a
1010   \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_UNBINDABLE}) facenti
1011   parte dell'infrastruttura degli \textit{shared subtree} introdotta a partire
1012   dal kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}.
1013   In questo caso \param{target} dovrà fare riferimento al \textit{mount point}
1014   che si intende marcare, e tutti gli altri argomenti verranno ignorati.
1015
1016   Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
1017   effettuati da un \textit{mount point} marcato da essa siano di tipo
1018   \textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di
1019   montaggio o smontaggio che avviene su una directory al di sotto del
1020   \textit{mount point} originale. Le operazioni di montaggio e smontaggio in
1021   questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
1022   originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
1023   essi potranno eseguire al loro interno ulteriori montaggi che non saranno
1024   propagati né negli altri né nel \textit{mount point} originale.
1025
1026 \item[\constd{MS\_STRICTATIME}] Ripristina il comportamento tradizionale per
1027   cui l'\textit{access time} viene aggiornato ad ogni accesso al
1028   file. L'opzione è disponibile solo a partire dal kernel 2.6.30 quando il
1029   comportamento di default del kernel è diventato quello fornito da
1030   \const{MS\_RELATIME}.
1031
1032 \item[\constd{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
1033   ogni modifica al contenuto del filesystem venga immediatamente registrata su
1034   disco. Lo stesso comportamento può essere ottenuto con il flag
1035   \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open_close}).
1036
1037   Questa opzione consente di ridurre al minimo il rischio di perdita dei dati
1038   in caso di crollo improvviso del sistema, al costo di una pesante perdita di
1039   prestazioni dato che tutte le funzioni di scrittura non saranno più
1040   bufferizzate e si bloccheranno fino all'arrivo dei dati sul disco. Per un
1041   compromesso in cui questo comportamento avviene solo per le directory, ed ha
1042   quindi una incidenza nettamente minore, si può usare \const{MS\_DIRSYNC}.
1043
1044 \item[\constd{MS\_UNBINDABLE}] Marca un \textit{mount point} come
1045   \textit{unbindable mount}. Si tratta di una delle nuove opzioni (insieme a
1046   \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_SLAVE}) facenti parte
1047   dell'infrastruttura degli \textit{shared subtree} introdotta a partire dal
1048   kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}.  In
1049   questo caso \param{target} dovrà fare riferimento al \textit{mount point}
1050   che si intende marcare, e tutti gli altri argomenti verranno ignorati.
1051
1052   Un \textit{mount point} marcato in questo modo disabilita la capacità di
1053   eseguire dei \textit{bind mount} del suo contenuto. Si comporta cioè come
1054   allo stesso modo di un \textit{mount point} ordinario di tipo
1055   \textit{private} con in più la restrizione che nessuna sua sottodirectory
1056   (anche se relativa ad un ulteriore montaggio) possa essere utilizzata per un
1057   come sorgente di un \textit{bind mount}.
1058
1059 \end{basedescript}
1060
1061 % NOTE per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE} e
1062 % \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, in particolare
1063 %  * http://lwn.net/Articles/159077/ e
1064 %  * Documentation/filesystems/sharedsubtree.txt
1065
1066 % TODO: (bassa priorità) non documentati ma presenti in sys/mount.h:
1067 %       * MS_POSIXACL
1068 %       * MS_KERNMOUNT
1069 %       * MS_I_VERSION
1070 %       * MS_ACTIVE
1071 %       * MS_NOUSER
1072
1073
1074 Una volta che non si voglia più utilizzare un certo filesystem è possibile
1075 ``\textsl{smontarlo}'' usando la funzione di sistema \funcd{umount}, il cui
1076 prototipo è:
1077
1078 \begin{funcproto}{
1079 \fhead{sys/mount.h}
1080 \fdecl{umount(const char *target)}
1081 \fdesc{Smonta un filesystem.} 
1082 }
1083 {La funzione ritorna  $0$ in caso di successo e $-1$ per un errore,
1084   nel qual caso \var{errno} assumerà uno dei valori: 
1085   \begin{errlist}
1086   \item[\errcode{EBUSY}] il filesystem è occupato.
1087   \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point}.
1088   \item[\errcode{EPERM}] il processo non ha i privilegi di
1089     amministratore.\footnotemark 
1090   \end{errlist}
1091   ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG},
1092   \errval{ENOENT}, \errval{ENOMEM} nel loro significato generico.  }
1093 \end{funcproto}
1094
1095 \footnotetext{più precisamente la capacità \const{CAP\_SYS\_ADMIN}, vedi
1096   sez.~\ref{sec:proc_capabilities}.}
1097
1098 La funzione prende il nome della directory su cui il filesystem è montato e
1099 non il file o il dispositivo che è stato montato,\footnote{questo è vero a
1100   partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la
1101   funzione poteva essere usata anche specificando il file di dispositivo.} in
1102 quanto a partire dai kernel della serie 2.4.x è possibile montare lo stesso
1103 dispositivo in più punti. Nel caso più di un filesystem sia stato montato
1104 sullo stesso \textit{mount point} viene smontato quello che è stato montato
1105 per ultimo. Si tenga presente che la funzione fallisce se il filesystem è
1106 ``\textsl{occupato}'', cioè quando ci sono ancora dei file aperti sul
1107 filesystem, se questo contiene la directory di lavoro (vedi
1108 sez.~\ref{sec:file_work_dir}) di un qualunque processo o il \textit{mount
1109   point} di un altro filesystem.
1110
1111 Linux provvede inoltre una seconda funzione di sistema, \funcd{umount2}, che
1112 consente un maggior controllo delle operazioni, come forzare lo smontaggio di
1113 un filesystem anche quando questo risulti occupato; il suo prototipo è:
1114
1115 \begin{funcproto}{
1116 \fhead{sys/mount.h}
1117 \fdecl{umount2(const char *target, int flags)}
1118 \fdesc{Smonta un filesystem.} 
1119 }
1120 {La funzione ritorna  $0$ in caso di successo e $-1$ per un errore,
1121   nel qual caso \var{errno} assumerà uno dei valori: 
1122   \begin{errlist}
1123      \item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
1124        ed il filesystem non era occupato.
1125      \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
1126        processo, o contiene dei file aperti, o un altro \textit{mount point}.
1127      \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point} o si
1128        è usato \const{MNT\_EXPIRE} con \const{MNT\_FORCE} o
1129        \const{MNT\_DETACH} o si è specificato un flag non esistente.
1130   \end{errlist}
1131   e tutti gli altri valori visti per \func{umount} con lo stesso significato.}
1132 \end{funcproto}
1133
1134 Il valore di \param{flags} è una maschera binaria dei flag che controllano le
1135 modalità di smontaggio, che deve essere specificato con un OR aritmetico delle
1136 costanti illustrate in tab.~\ref{tab:umount2_flags}.  Specificando
1137 \constd{MNT\_FORCE} la funzione cercherà di liberare il filesystem anche se è
1138 occupato per via di una delle condizioni descritte in precedenza. A seconda
1139 del tipo di filesystem alcune (o tutte) possono essere superate, evitando
1140 l'errore di \errcode{EBUSY}. In tutti i casi prima dello smontaggio viene
1141 eseguita una sincronizzazione dei dati.
1142
1143 \begin{table}[!htb]
1144   \centering
1145   \footnotesize
1146   \begin{tabular}[c]{|l|p{8cm}|}
1147     \hline
1148     \textbf{Costante} & \textbf{Descrizione}\\
1149     \hline
1150     \hline
1151     \const{MNT\_FORCE}  & Forza lo smontaggio del filesystem anche se questo è
1152                            occupato (presente dai kernel della serie 2.2).\\
1153     \const{MNT\_DETACH} & Esegue uno smontaggio ``\textsl{pigro}'', in cui si
1154                            blocca l'accesso ma si aspetta che il filesystem si
1155                            liberi (presente dal kernel 2.4.11 e dalla
1156                            \acr{glibc} 2.11).\\ 
1157     \const{MNT\_EXPIRE} & Se non occupato marca un \textit{mount point} come
1158                            ``\textsl{in scadenza}'' in modo che ad una
1159                            successiva chiamata senza utilizzo del filesystem
1160                            questo venga smontato (presente dal 
1161                            kernel 2.6.8 e dalla \acr{glibc} 2.11).\\ 
1162     \const{UMOUNT\_NOFOLLOW}& Non dereferenzia \param{target} se questo è un
1163                                collegamento simbolico (vedi
1164                                sez.~\ref{sec:link_symlink_rename}) evitando
1165                                problemi di sicurezza (presente dal kernel
1166                                2.6.34).\\  
1167     \hline
1168   \end{tabular}
1169   \caption{Costanti che identificano i bit dell'argomento \param{flags}
1170     della funzione \func{umount2}.} 
1171   \label{tab:umount2_flags}
1172 \end{table}
1173
1174 Con l'opzione \constd{MNT\_DETACH} si richiede invece uno smontaggio
1175 ``\textsl{pigro}'' (o \textit{lazy umount}) in cui il filesystem diventa
1176 inaccessibile per i nuovi processi subito dopo la chiamata della funzione, ma
1177 resta accessibile per quelli che lo hanno ancora in uso e non viene smontato
1178 fintanto che resta occupato.
1179
1180 Con \constd{MNT\_EXPIRE}, che non può essere specificato insieme agli altri
1181 due, si marca il \textit{mount point} di un filesystem non occupato come
1182 ``\textsl{in scadenza}'', in tal caso \func{umount2} ritorna con un errore di
1183 \errcode{EAGAIN}, mentre in caso di filesystem occupato si sarebbe ricevuto
1184 \errcode{EBUSY}.  Una volta marcato, se nel frattempo non viene fatto nessun
1185 uso del filesystem, ad una successiva chiamata con \const{MNT\_EXPIRE} questo
1186 verrà smontato. Questo flag consente di realizzare un meccanismo che smonti
1187 automaticamente i filesystem che restano inutilizzati per un certo periodo di
1188 tempo.
1189
1190 Infine il flag \constd{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se
1191 questo è un collegamento simbolico (vedi
1192 sez.~\ref{sec:link_symlink_rename}). Questa è una misura di sicurezza
1193 introdotta per evitare, per quei filesystem per il quale è prevista una
1194 gestione diretta da parte degli utenti, come quelli basati su
1195 FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
1196   interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
1197   di implementarne le funzioni in \textit{user space}, così da rendere
1198   possibile l'implementazione di un qualunque filesystem (con applicazioni di
1199   grande interesse come il filesystem cifrato \textit{encfs} o il filesystem
1200   di rete \textit{sshfs}) che possa essere usato direttamente per conto degli
1201   utenti.}  che si possano passare ai programmi che effettuano lo smontaggio
1202 dei filesystem, che in genere sono privilegiati ma consentono di agire solo
1203 sui propri \textit{mount point}, dei collegamenti simbolici che puntano ad
1204 altri \textit{mount point}, ottenendo così la possibilità di smontare
1205 qualunque filesystem.
1206
1207
1208 Altre due funzioni di sistema specifiche di Linux,\footnote{esse si trovano
1209   anche su BSD, ma con una struttura diversa.} utili per ottenere in maniera
1210 diretta informazioni riguardo al filesystem su cui si trova un certo file,
1211 sono \funcd{statfs} e \funcd{fstatfs}, i cui prototipi sono:
1212
1213 \begin{funcproto}{
1214 \fhead{sys/vfs.h}
1215 \fdecl{int statfs(const char *path, struct statfs *buf)}
1216 \fdecl{int fstatfs(int fd, struct statfs *buf)}
1217 \fdesc{Restituiscono informazioni relative ad un filesystem.} 
1218 }
1219 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore,
1220   nel qual caso \var{errno} assumerà uno dei valori: 
1221   \begin{errlist}
1222   \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato
1223     non supporta la funzione.
1224   \end{errlist} ed inoltre \errval{EFAULT} ed \errval{EIO} per entrambe,
1225   \errval{EBADF} per \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
1226   \errval{ENOENT}, \errval{EACCES}, \errval{ELOOP} per \func{statfs} nel loro
1227   significato generico.}
1228 \end{funcproto}
1229
1230 Queste funzioni permettono di ottenere una serie di informazioni generali
1231 riguardo al filesystem su cui si trova il file specificato con un
1232 \textit{pathname} per \func{statfs} e con un file descriptor (vedi
1233 sez.~\ref{sec:file_fd}) per \func{statfs}.  Le informazioni vengono restituite
1234 all'indirizzo \param{buf} di una struttura \struct{statfs} definita come in
1235 fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il filesystem in
1236 esame sono impostati a zero.  I valori del campo \var{f\_type} sono definiti
1237 per i vari filesystem nei relativi file di header dei sorgenti del kernel da
1238 costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in genere è il nome
1239 del filesystem stesso.
1240
1241 \begin{figure}[!htb]
1242   \footnotesize \centering
1243   \begin{minipage}[c]{0.8\textwidth}
1244     \includestruct{listati/statfs.h}
1245   \end{minipage}
1246   \normalsize 
1247   \caption{La struttura \structd{statfs}.} 
1248   \label{fig:sys_statfs}
1249 \end{figure}
1250
1251 \conffilebeg{/etc/mtab} 
1252
1253 La \acr{glibc} provvede infine una serie di funzioni per la gestione dei due
1254 file \conffiled{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
1255   \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
1256 ed \conffile{/etc/mtab}\footnote{più precisamente \funcm{setmntent},
1257   \funcm{getmntent},\funcm{getmntent\_r}, \funcm{addmntent},\funcm{endmntent},
1258   \funcm{hasmntopt}.} che convenzionalmente sono usati in quasi tutti i
1259 sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai
1260 filesystem da montare e a quelli correntemente montati. Le funzioni servono a
1261 leggere il contenuto di questi file in opportune strutture \structd{fstab} e
1262 \structd{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e
1263 rimuovere le voci presenti nel file.
1264
1265 In generale si dovrebbero usare queste funzioni, in particolare quelle
1266 relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
1267 effettua il montaggio di un filesystem. In realtà in questi casi è molto più
1268 semplice invocare direttamente il programma \cmd{mount}. Inoltre l'uso stesso
1269 di \conffile{/etc/mtab} è considerato una pratica obsoleta, in quanto se non
1270 aggiornato correttamente (cosa che è impossibile se la radice è montata in
1271 sola lettura) il suo contenuto diventa fuorviante.
1272
1273 Per questo motivo il suo utilizzo viene deprecato ed in molti casi viene già
1274 oggi sostituito da un collegamento simbolico a \procfile{/proc/mounts}, che
1275 contiene una versione degli stessi contenuti (vale a dire l'elenco dei
1276 filesystem montati) generata direttamente dal kernel, e quindi sempre
1277 disponibile e sempre aggiornata. Per questo motivo tralasceremo la
1278 trattazione, di queste funzioni, rimandando al manuale della \acr{glibc}
1279 \cite{GlibcMan} per la documentazione completa.
1280
1281 \conffileend{/etc/mtab}
1282
1283 % TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
1284 % TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...) 
1285
1286
1287
1288 \section{La gestione di file e directory}
1289 \label{sec:file_dir}
1290
1291 In questa sezione esamineremo le funzioni usate per la manipolazione dei nomi
1292 file e directory, per la creazione di collegamenti simbolici e diretti, per la
1293 gestione e la lettura delle directory.  In particolare ci soffermeremo sulle
1294 conseguenze che derivano dalla architettura di un filesystem unix-like
1295 illustrata in sez.~\ref{sec:file_filesystem} per quanto attiene il
1296 comportamento e gli effetti delle varie funzioni. Tratteremo infine la
1297 directory di lavoro e le funzioni per la gestione di file speciali e
1298 temporanei.
1299
1300
1301 \subsection{La gestione dei nomi dei file}
1302 \label{sec:link_symlink_rename}
1303
1304 % \subsection{Le funzioni \func{link} e \func{unlink}}
1305 % \label{sec:file_link}
1306
1307 Una caratteristica comune a diversi sistemi operativi è quella di poter creare
1308 dei nomi alternativi, come gli alias del vecchio MacOS o i collegamenti di
1309 Windows o i nomi logici del VMS, che permettono di fare riferimento allo
1310 stesso file chiamandolo con nomi diversi o accedendovi da directory diverse.
1311 Questo è possibile anche in ambiente Unix, dove un nome alternativo viene
1312 usualmente chiamato ``\textsl{collegamento}'' (o \textit{link}).  Data
1313 l'architettura del sistema riguardo la gestione dei file vedremo però che ci
1314 sono due metodi sostanzialmente diversi per fare questa operazione.
1315
1316 \itindbeg{hard~link}
1317 \index{collegamento!diretto|(}
1318
1319 In sez.~\ref{sec:file_filesystem} abbiamo spiegato come la capacità di
1320 chiamare un file con nomi diversi sia connaturata con l'architettura di un
1321 filesystem per un sistema Unix, in quanto il nome del file che si trova in una
1322 directory è solo un'etichetta associata ad un puntatore che permette di
1323 ottenere il riferimento ad un \textit{inode}, e che è quest'ultimo che viene
1324 usato dal kernel per identificare univocamente gli oggetti sul filesystem.
1325
1326 Questo significa che fintanto che si resta sullo stesso filesystem la
1327 realizzazione di un \textit{link} è immediata: uno stesso file può avere tanti
1328 nomi diversi, dati da altrettante associazioni diverse allo stesso
1329 \textit{inode} effettuate tramite ``etichette'' diverse in directory
1330 diverse. Si noti anche come nessuno di questi nomi possa assumere una
1331 particolare preferenza o originalità rispetto agli altri, in quanto tutti
1332 fanno comunque riferimento allo stesso \textit{inode} e quindi tutti
1333 otterranno lo stesso file.
1334
1335 Quando si vuole aggiungere ad una directory una voce che faccia riferimento ad
1336 un file già esistente nella modalità appena descritta, per ottenere quello che
1337 viene denominato ``\textsl{collegamento diretto}'' (o \textit{hard link}), si
1338 deve usare la funzione di sistema \funcd{link}, il cui prototipo è:
1339
1340 \begin{funcproto}{
1341 \fhead{unistd.h}
1342 \fdecl{int link(const char *oldpath, const char *newpath)}
1343 \fdesc{Crea un nuovo collegamento diretto (\textit{hard link}).} 
1344 }
1345 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
1346   nel qual caso \var{errno} assumerà uno dei valori: 
1347   \begin{errlist}
1348   \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
1349     esiste già.
1350   \item[\errcode{EMLINK}] ci sono troppi collegamenti al file \param{oldpath}
1351     (il numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
1352     sez.~\ref{sec:sys_limits}).
1353   \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
1354     \param{newpath} non supporta i collegamenti diretti o è una directory.
1355   \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
1356     riferimento ad un filesystem montato sullo stesso 
1357     \textit{mount point}.
1358   \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
1359   \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
1360   \errval{ENOSPC}, \errval{ENOTDIR}, \errval{EROFS} nel loro significato
1361   generico.}
1362 \end{funcproto}
1363
1364 La funzione crea in \param{newpath} un collegamento diretto al file indicato
1365 da \param{oldpath}. Per quanto detto la creazione di un nuovo collegamento
1366 diretto non copia il contenuto del file, ma si limita a creare la voce
1367 specificata da \param{newpath} nella directory corrispondente e l'unica
1368 proprietà del file che verrà modificata sarà il numero di riferimenti al file
1369 (il campo \var{i\_nlink} della struttura \kstruct{inode}, vedi
1370 fig.~\ref{fig:kstruct_inode}) che verrà aumentato di di uno. In questo modo lo
1371 stesso file potrà essere acceduto sia con \param{newpath} che
1372 con \param{oldpath}.
1373
1374 Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
1375 collegamento diretto è possibile solo se entrambi i \textit{pathname} sono
1376 nello stesso filesystem ed inoltre esso deve supportare gli \textit{hard link}
1377 (il meccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di
1378 Windows). In realtà la funzione ha un ulteriore requisito, e cioè che non solo
1379 che i due file siano sullo stesso filesystem, ma anche che si faccia
1380 riferimento ad essi all'interno dello stesso \textit{mount point}.\footnote{si
1381   tenga presente infatti, come detto in sez.~\ref{sec:filesystem_mounting},
1382   che a partire dal kernel 2.4 uno stesso filesystem può essere montato più
1383   volte su directory diverse.}
1384
1385 La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
1386 filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
1387 l'amministratore è in grado di creare un collegamento diretto ad un'altra
1388 directory: questo viene fatto perché con una tale operazione è possibile
1389 creare dei \textit{loop} nel filesystem (vedi fig.~\ref{fig:file_link_loop})
1390 che molti programmi non sono in grado di gestire e la cui rimozione
1391 diventerebbe piuttosto complicata.\footnote{in genere per questo tipo di
1392   errori occorre eseguire il programma \cmd{fsck} per riparare il filesystem,
1393   in quanto in caso di \textit{loop} la directory creata non sarebbe vuota e
1394   non si potrebbe più rimuoverla.}
1395
1396 Data la pericolosità di questa operazione e la disponibilità dei collegamenti
1397 simbolici (che vedremo a breve) e dei \textit{bind mount}
1398 (già visti in sez.~\ref{sec:filesystem_mounting}) che possono fornire la
1399 stessa funzionalità senza questi problemi, nel caso di Linux questa capacità è
1400 stata completamente disabilitata, e al tentativo di creare un collegamento
1401 diretto ad una directory la funzione \func{link} restituisce sempre l'errore
1402 \errcode{EPERM}.
1403
1404 Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
1405 \textit{hard link} ad un collegamento simbolico. In questo caso lo standard
1406 POSIX.1-2001 prevederebbe che quest'ultimo venga risolto e che il collegamento
1407 sia effettuato rispetto al file cui esso punta, e che venga riportato un
1408 errore qualora questo non esista o non sia un file. Questo era anche il
1409 comportamento iniziale di Linux ma a partire dai kernel della serie
1410 2.0.x\footnote{per la precisione il comportamento era quello previsto dallo
1411   standard POSIX fino al kernel di sviluppo 1.3.56, ed è stato temporaneamente
1412   ripristinato anche durante lo sviluppo della serie 2.1.x, per poi tornare al
1413   comportamento attuale fino ad oggi (per riferimento si veda
1414   \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento
1415 che non segue più lo standard per cui l'\textit{hard link} viene creato nei
1416 confronti del collegamento simbolico, e non del file cui questo punta. La
1417 revisione POSIX.1-2008 lascia invece il comportamento dipendente
1418 dall'implementazione, cosa che rende Linux conforme a questa versione
1419 successiva dello standard.
1420
1421 \itindbeg{symbolic~link}
1422 \index{collegamento!simbolico|(}
1423
1424 La ragione di questa differenza rispetto al vecchio standard, presente anche
1425 in altri sistemi unix-like, è dovuta al fatto che un collegamento simbolico
1426 può fare riferimento anche ad un file non esistente o a una directory, per i
1427 quali l'\textit{hard link} non può essere creato, per cui la scelta di seguire
1428 il collegamento simbolico è stata ritenuta una scelta scorretta nella
1429 progettazione dell'interfaccia.  Infatti se non ci fosse il comportamento
1430 adottato da Linux sarebbe impossibile creare un \textit{hard link} ad un
1431 collegamento simbolico, perché la funzione lo risolverebbe e l'\textit{hard
1432   link} verrebbe creato verso la destinazione. Invece evitando di seguire lo
1433 standard l'operazione diventa possibile, ed anche il comportamento della
1434 funzione risulta molto più comprensibile. Tanto più che se proprio se si vuole
1435 creare un \textit{hard link} rispetto alla destinazione di un collegamento
1436 simbolico è sempre possibile farlo direttamente.\footnote{ciò non toglie che
1437   questo comportamento possa causare problemi, come nell'esempio descritto
1438   nell'articolo citato nella nota precedente, a programmi che non si aspettano
1439   questa differenza rispetto allo standard POSIX.}
1440
1441 Dato che \func{link} crea semplicemente dei nomi che fanno riferimenti agli
1442 \textit{inode}, essa può funzionare soltanto per file che risiedono sullo
1443 stesso filesystem e solo per un filesystem di tipo Unix.  Inoltre abbiamo
1444 visto che in Linux non è consentito eseguire un collegamento diretto ad una
1445 directory.
1446
1447 Per ovviare a queste limitazioni, come accennato all'inizio, i sistemi
1448 unix-like supportano un'altra forma di collegamento, detta
1449 ``\textsl{collegamento simbolico}'' (o anche \textit{soft link} o
1450 \textit{symbolic link}). In questo caso si tratta, come avviene in altri
1451 sistemi operativi, di file speciali che contengono semplicemente il
1452 riferimento ad un altro file (o directory). In questo modo è possibile
1453 effettuare \textit{link} anche attraverso filesystem diversi, a file posti in
1454 filesystem che non supportano i collegamenti diretti, a delle directory, ed
1455 anche a file che non esistono ancora.
1456
1457 \itindend{hard~link}
1458 \index{collegamento!diretto|)}
1459
1460 Il meccanismo funziona in quanto i \textit{symbolic link} sono riconosciuti
1461 come tali dal kernel\footnote{è uno dei diversi tipi di file visti in
1462   tab.~\ref{tab:file_file_types}, contrassegnato come tale nell'\textit{inode}
1463   e riconoscibile dal valore del campo \var{st\_mode} della struttura
1464   \struct{stat} (vedi sez.~\ref{sec:file_stat}).} e tutta una serie di
1465 funzioni di sistema (come \func{open} o \func{stat}) quando ricevono come
1466 argomento il \textit{pathname} di un collegamento simbolico vanno
1467 automaticamente ad operare sul file da esso specificato. La funzione di
1468 sistema che permette di creare un nuovo collegamento simbolico è
1469 \funcd{symlink}, ed il suo prototipo è:
1470
1471 \begin{funcproto}{
1472 \fhead{unistd.h}
1473 \fdecl{int symlink(const char *oldpath, const char *newpath)}
1474 \fdesc{Crea un nuovo collegamento simbolico (\textit{symbolic link}).} 
1475 }
1476 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
1477   nel qual caso \var{errno} assumerà uno dei valori: 
1478   \begin{errlist}
1479   \item[\errcode{EEXIST}] esiste già un file \param{newpath}.
1480   \item[\errcode{ENOENT}] una componente di \param{newpath} non esiste o
1481     \param{oldpath} è una stringa vuota.
1482   \item[\errcode{EPERM}] il filesystem che contiene \param{newpath} non
1483     supporta i collegamenti simbolici.
1484   \item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
1485     lettura.
1486   \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
1487   \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOMEM}, \errval{ENOSPC} e
1488   \errval{ENOTDIR} nel loro significato generico.}
1489 \end{funcproto}
1490
1491 La funzione crea un nuovo collegamento simbolico \param{newpath} che fa
1492 riferimento ad \param{oldpath}.  Si tenga presente che la funzione non
1493 effettua nessun controllo sull'esistenza di un file di nome \param{oldpath},
1494 ma si limita ad inserire il \textit{pathname} nel collegamento
1495 simbolico. Pertanto un collegamento simbolico può anche riferirsi ad un file
1496 che non esiste ed in questo caso si ha quello che viene chiamato un
1497 \itindex{dangling~link} \textit{dangling link}, letteralmente un
1498 \index{collegamento!ciondolante} ``\textsl{collegamento ciondolante}''.
1499
1500 Come accennato i collegamenti simbolici sono risolti automaticamente dal
1501 kernel all'invocazione delle varie \textit{system call}. In
1502 tab.~\ref{tab:file_symb_effect} si è riportato un elenco dei comportamenti
1503 delle varie funzioni di sistema che operano sui file nei confronti della
1504 risoluzione dei collegamenti simbolici, specificando quali li seguono e quali
1505 invece possono operare direttamente sui loro contenuti.
1506 \begin{table}[htb]
1507   \centering
1508   \footnotesize
1509   \begin{tabular}[c]{|l|c|c|}
1510     \hline
1511     \textbf{Funzione} & \textbf{Segue il link} & \textbf{Non segue il link} \\
1512     \hline 
1513     \hline 
1514     \func{access}   & $\bullet$ & --        \\
1515     \func{chdir}    & $\bullet$ & --        \\
1516     \func{chmod}    & $\bullet$ & --        \\
1517     \func{chown}    & --        & $\bullet$ \\
1518     \func{creat}    & $\bullet$ & --        \\
1519     \func{exec}     & $\bullet$ & --        \\
1520     \func{lchown}   & $\bullet$ & --        \\
1521     \func{link}\footnotemark & --        & $\bullet$ \\
1522     \func{lstat}    & --        & $\bullet$ \\
1523     \func{mkdir}    & $\bullet$ & --        \\
1524     \func{mkfifo}   & $\bullet$ & --        \\
1525     \func{mknod}    & $\bullet$ & --        \\
1526     \func{open}     & $\bullet$ & --        \\
1527     \func{opendir}  & $\bullet$ & --        \\
1528     \func{pathconf} & $\bullet$ & --        \\
1529     \func{readlink} & --        & $\bullet$ \\
1530     \func{remove}   & --        & $\bullet$ \\
1531     \func{rename}   & --        & $\bullet$ \\
1532     \func{stat}     & $\bullet$ & --        \\
1533     \func{truncate} & $\bullet$ & --        \\
1534     \func{unlink}   & --        & $\bullet$ \\
1535     \hline 
1536   \end{tabular}
1537   \caption{Uso dei collegamenti simbolici da parte di alcune funzioni.}
1538   \label{tab:file_symb_effect}
1539 \end{table}
1540
1541 \footnotetext{a partire dalla serie 2.0, e contrariamente a quanto indicato
1542   dallo standard POSIX.1-2001.}
1543
1544 Si noti che non si è specificato il comportamento delle funzioni che operano
1545 con i file descriptor (che tratteremo nel prossimo capitolo), in quanto la
1546 risoluzione del collegamento simbolico viene in genere effettuata dalla
1547 funzione che restituisce il file descriptor (normalmente la \func{open}, vedi
1548 sez.~\ref{sec:file_open_close}) e tutte le operazioni seguenti fanno
1549 riferimento solo a quest'ultimo.
1550
1551 Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
1552 \func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
1553 accedere alle informazioni del collegamento invece che a quelle del file a cui
1554 esso fa riferimento. Quando si vuole leggere il contenuto di un collegamento
1555 simbolico si usa la funzione di sistema \funcd{readlink}, il cui prototipo è:
1556
1557 \begin{funcproto}{
1558 \fhead{unistd.h}
1559 \fdecl{int readlink(const char *path, char *buff, size\_t size)}
1560 \fdesc{Legge il contenuto di un collegamento simbolico.} 
1561 }
1562 {La funzione ritorna il numero di caratteri letti dentro \param{buff} in caso
1563   di successo e $-1$ per un errore,  nel qual caso \var{errno} assumerà uno
1564   dei valori:
1565   \begin{errlist}
1566   \item[\errcode{EINVAL}] \param{path} non è un collegamento simbolico
1567     o \param{size} non è positiva.
1568   \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
1569   \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM} e
1570   \errval{ENOTDIR} nel loro significato generico.}
1571 \end{funcproto}
1572
1573 La funzione legge il \textit{pathname} a cui fa riferimento il collegamento
1574 simbolico indicato dall'argomento \param{path} scrivendolo sul
1575 buffer \param{buff} di dimensione \param{size}. Si tenga presente che la
1576 funzione non termina la stringa con un carattere nullo e che se questa è
1577 troppo lunga la tronca alla dimensione specificata da \param{size} per evitare
1578 di sovrascrivere oltre le dimensioni del buffer.
1579
1580 \begin{figure}[htb]
1581   \centering
1582   \includegraphics[width=8.5cm]{img/link_loop}
1583   \caption{Esempio di loop nel filesystem creato con un collegamento
1584     simbolico.}
1585   \label{fig:file_link_loop}
1586 \end{figure}
1587
1588 Come accennato uno dei motivi per cui non sono consentiti \textit{hard link}
1589 alle directory è che questi possono creare dei \textit{loop} nella risoluzione
1590 dei nomi che non possono essere eliminati facilmente. Invece è sempre
1591 possibile, ed in genere anche molto utile, creare un collegamento simbolico ad
1592 una directory, anche se in questo caso si potranno ottenere anche dei
1593 \textit{loop}. La situazione è illustrata in fig.~\ref{fig:file_link_loop},
1594 che riporta la struttura della directory \file{/boot}. Come si vede si è
1595 creato al suo interno un collegamento simbolico che punta di nuovo a
1596 \file{/boot}.\footnote{il \textit{loop} mostrato in
1597   fig.~\ref{fig:file_link_loop} è stato usato per poter permettere a
1598   \cmd{grub} (un bootloader in grado di leggere direttamente da vari
1599   filesystem il file da lanciare come sistema operativo) di vedere i file
1600   contenuti nella directory \file{/boot} con lo stesso \textit{pathname} con
1601   cui verrebbero visti dal sistema operativo, anche se essi si trovano, come
1602   accade spesso, su una partizione separata (che \cmd{grub} all'avvio vedrebbe 
1603   come \file{/}).}
1604
1605 Questo però può causare problemi per tutti quei programmi che effettuano la
1606 scansione di una directory senza tener conto dei collegamenti simbolici, ad
1607 esempio se lanciassimo un comando del tipo \code{grep -r linux *}, il loop
1608 nella directory porterebbe il comando ad esaminare \file{/boot},
1609 \file{/boot/boot}, \file{/boot/boot/boot} e così via.
1610
1611 Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
1612 un \textit{pathname} possano essere seguiti fino ad un certo numero massimo di
1613 collegamenti simbolici, il cui valore limite è specificato dalla costante
1614 \constd{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
1615 errore ed \var{errno} viene impostata al valore \errcode{ELOOP}, che nella
1616 quasi totalità dei casi indica appunto che si è creato un collegamento
1617 simbolico che fa riferimento ad una directory del suo stesso
1618 \textit{pathname}.
1619
1620 Un altro punto da tenere sempre presente è che, come abbiamo accennato, un
1621 collegamento simbolico può fare riferimento anche ad un file che non esiste;
1622 ad esempio possiamo usare il comando \cmd{ln} per creare un collegamento
1623 simbolico nella nostra directory con:
1624 \begin{Console}
1625 piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
1626 \end{Console}
1627 %$
1628 e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
1629 \begin{Console}
1630 piccardi@hain:~/gapil$ \textbf{ls symlink}
1631 symlink
1632 \end{Console}
1633 %$
1634 ma questo può generare confusione, perché accedendo in sola lettura a
1635 \file{symlink}, ad esempio con \cmd{cat}, otterremmo un errore:
1636 \begin{Console}
1637 piccardi@hain:~/gapil$ \textbf{cat symlink}
1638 cat: symlink: No such file or directory
1639 \end{Console}
1640 %$
1641 con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato
1642 l'esistenza di \file{symlink}, se invece scrivessimo su \file{symlink}
1643 otterremmo la creazione di \file{/tmp/tmp\_file} senza errori.
1644
1645
1646 \itindend{symbolic~link}
1647 \index{collegamento!simbolico|)}
1648
1649 Un'altra funzione relativa alla gestione dei nomi dei file, anche se a prima
1650 vista parrebbe riguardare un argomento completamente diverso, è quella che per
1651 la cancellazione di un file. In realtà una \textit{system call} che serva
1652 proprio a cancellare un file non esiste neanche perché, come accennato in
1653 sez.~\ref{sec:file_filesystem}, quando in un sistema unix-like si richiede la
1654 rimozione di un file quella che si va a cancellare è soltanto la voce che
1655 referenzia il suo \textit{inode} all'interno di una directory.
1656
1657 La funzione di sistema che consente di effettuare questa operazione, il cui
1658 nome come si può notare ha poco a che fare con il concetto di rimozione, è
1659 \funcd{unlink}, ed il suo prototipo è:
1660
1661 \begin{funcproto}{
1662 \fhead{unistd.h}
1663 \fdecl{int unlink(const char *pathname)}
1664 \fdesc{Cancella un file.} 
1665 }
1666 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
1667   nel qual caso \var{errno} assumerà uno dei valori:\footnotemark  
1668   \begin{errlist}
1669   \item[\errcode{EACCES}] non si ha il permesso di scrittura sulla directory
1670     che contiene \param{pathname} o di attraversamento di una delle directory
1671     superiori. 
1672   \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una
1673     directory.
1674   \item[\errcode{EPERM}] il filesystem non consente l'operazione, o la
1675     directory che contiene \param{pathname} ha lo \textit{sticky bit} e non si
1676     è il proprietario o non si hanno privilegi amministrativi. 
1677   \end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
1678   \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EROFS} nel loro
1679   significato generico.}
1680 \end{funcproto}
1681
1682 \footnotetext{questa funzione su Linux ha alcune peculiarità nei codici di
1683   errore, in particolare riguardo la rimozione delle directory che non è mai
1684   permessa e che causa l'errore \errcode{EISDIR}; questo è un valore specifico
1685   di Linux non conforme allo standard POSIX che prescrive invece l'uso di
1686   \errcode{EPERM} in caso l'operazione non sia consentita o il processo non
1687   abbia privilegi sufficienti, valore che invece Linux usa anche se il
1688   filesystem non supporta la funzione, inoltre il codice \errcode{EBUSY} nel
1689   caso la directory sia occupata su Linux non esiste.}
1690
1691 La funzione elimina il nome specificato dall'argomento \param{pathname} nella
1692 directory che lo contiene e decrementa il numero di riferimenti nel relativo
1693 \textit{inode}.\footnote{come per \func{link} queste due operazioni sono
1694   effettuate all'interno della \textit{system call} in maniera atomica.} Nel
1695 caso di socket, \textit{fifo} o file di dispositivo rimuove il nome, ma come
1696 per i file normali i processi che hanno aperto uno di questi oggetti possono
1697 continuare ad utilizzarli.  Nel caso di cancellazione di un collegamento
1698 simbolico, che consiste solo nel rimando ad un altro file, questo viene
1699 immediatamente eliminato.
1700
1701 Per cancellare una voce in una directory è necessario avere il permesso di
1702 scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
1703 il diritto di esecuzione/attraversamento sulla directory che la contiene
1704 (affronteremo in dettaglio l'argomento dei permessi di file e directory in
1705 sez.~\ref{sec:file_access_control}). Se inoltre lo \textit{sticky bit} (vedi
1706 sez.~\ref{sec:file_special_perm}) è impostato occorrerà anche essere
1707 proprietari del file o proprietari della directory o avere i privilegi di
1708 amministratore.
1709
1710 Si ricordi inoltre che anche se se ne è rimosso il nome da una directory, un
1711 file non viene eliminato dal disco fintanto che tutti i riferimenti ad esso
1712 sono stati cancellati: solo quando il numero di collegamenti mantenuto
1713 nell'\textit{inode} diventa nullo, questo viene disallocato e lo spazio
1714 occupato su disco viene liberato. Si tenga presente comunque che a questo si
1715 aggiunge sempre un'ulteriore condizione e cioè che non ci siano processi che
1716 abbiano il suddetto file aperto.\footnote{come vedremo in
1717   sez.~\ref{sec:file_unix_interface} il kernel mantiene anche una tabella dei
1718   file aperti nei vari processi, che a sua volta contiene i riferimenti agli
1719   \textit{inode} ad essi relativi; prima di procedere alla cancellazione dello
1720   spazio occupato su disco dal contenuto di un file il kernel controlla anche
1721   questa tabella, per verificare che anche in essa non ci sia più nessun
1722   riferimento all'\textit{inode} in questione.}
1723
1724 Questa caratteristica del sistema può essere usata per essere sicuri di non
1725 lasciare file temporanei su disco in caso di crash di un programma. La tecnica
1726 è quella di aprire un nuovo file e chiamare \func{unlink} su di esso subito
1727 dopo, in questo modo il contenuto del file sarà sempre disponibile all'interno
1728 del processo attraverso il suo file descriptor (vedi sez.~\ref{sec:file_fd}),
1729 ma non ne resta traccia in nessuna directory, e lo spazio occupato su disco
1730 viene immediatamente rilasciato alla conclusione del processo, quando tutti i
1731 file vengono chiusi.
1732
1733 Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
1734 la funzione \func{unlink} sulle directory, nel qual caso si otterrebbe un
1735 errore di \errcode{EISDIR}. Per cancellare una directory si deve usare la
1736 apposita funzione di sistema \func{rmdir} (che vedremo in
1737 sez.~\ref{sec:file_dir_creat_rem}), oppure la funzione \func{remove}.
1738 Quest'ultima è la funzione prevista dallo standard ANSI C per effettuare una
1739 cancellazione generica di un file o di una directory e funziona anche per i
1740 sistemi operativo che non supportano gli \textit{hard link}. Nei sistemi
1741 unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
1742 \func{unlink} per i file ed \func{rmdir} per le directory; il suo prototipo è:
1743
1744 \begin{funcproto}{
1745 \fhead{stdio.h}
1746 \fdecl{int remove(const char *pathname)}
1747 \fdesc{Cancella un file o una directory.} 
1748 }
1749 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1750   caso \var{errno} assumerà uno dei valori relativi alla chiamata utilizzata,
1751   pertanto si può fare riferimento a quanto illustrato nelle descrizioni di
1752   \func{unlink} e \func{rmdir}.}
1753 \end{funcproto}
1754
1755 La funzione utilizza la funzione \func{unlink} per cancellare i file e la
1756 funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per cancellare
1757 le directory.\footnote{questo vale usando la \acr{glibc}; nella libc4 e nella
1758   libc5 la funzione \func{remove} era un semplice alias alla funzione
1759   \func{unlink} e quindi non poteva essere usata per le directory.} Si tenga
1760 presente che per alcune implementazioni del protocollo NFS utilizzare questa
1761 funzione può comportare la scomparsa di file ancora in uso.
1762
1763 Infine per cambiare nome ad un file o a una directory si usa la funzione di
1764 sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C,
1765   ma si applica solo per i file, lo standard POSIX estende la funzione anche
1766   alle directory.} il cui prototipo è:
1767
1768 \begin{funcproto}{
1769 \fhead{stdio.h}
1770 \fdecl{int rename(const char *oldpath, const char *newpath)}
1771 \fdesc{Rinomina un file o una directory.} 
1772 }
1773 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
1774   nel qual caso \var{errno} assumerà uno dei valori: 
1775   \begin{errlist}
1776   \item[\errcode{EACCESS}] non c'è permesso di scrivere nelle directory
1777     contenenti \param{oldpath} e \param{newpath} o di attraversare 
1778     quelle dei loro \textit{pathname} o di scrivere su \param{newpath}
1779     se questa è una directory.
1780   \item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
1781     parte di qualche processo (come directory di lavoro o come radice) o del
1782     sistema (come \textit{mount point}) ed il sistema non riesce a risolvere
1783     la situazione.
1784   \item[\errcode{EEXIST}] \param{newpath} è una directory già esistente e
1785     non è vuota (anche \errcode{ENOTEMPTY}).
1786   \item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
1787     \param{oldpath} o più in generale si è cercato di creare una directory come
1788     sotto-directory di sé stessa.
1789   \item[\errcode{EISDIR}] \param{newpath} è una directory mentre
1790     \param{oldpath} non è una directory.
1791   \item[\errcode{ENOTDIR}] uno dei componenti dei \textit{pathname} non è una
1792     directory o \param{oldpath} è una directory e 
1793     \param{newpath} esiste e non è una directory.
1794   \item[\errval{EPERM}] la directory contenente \param{oldpath} o quella
1795     contenente un \param{newpath} esistente hanno lo \textit{sticky bit} e non
1796     si è i proprietari dei rispettivi file (o non si hanno privilegi
1797     amministrativi) oppure il filesystem non supporta l'operazione. 
1798   \item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo
1799     stesso filesystem e sotto lo stesso \textit{mount point}. 
1800   \end{errlist} ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{EMLINK},
1801   \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOSPC} e
1802   \errval{EROFS} nel loro significato generico.}
1803 \end{funcproto}
1804
1805 La funzione rinomina in \param{newpath} il file o la directory indicati
1806 dall'argomento \param{oldpath}. Il nome viene eliminato nella directory
1807 originale e ricreato nella directory di destinazione mantenendo il riferimento
1808 allo stesso \textit{inode}. Non viene spostato nessun dato e l'\textit{inode}
1809 del file non subisce nessuna modifica in quanto le modifiche sono eseguite
1810 sulle directory che contengono \param{newpath} ed \param{oldpath}.
1811
1812 Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di
1813 \func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
1814 c'è modifica, per quanto temporanea, al \textit{link count} del file e non può
1815 esistere un istante in cui un altro processo possa trovare attivi entrambi i
1816 nomi per lo stesso file se la destinazione non esiste o in cui questa sparisca
1817 temporaneamente se già esiste.
1818
1819 Dato che opera in maniera analoga la funzione è soggetta alle stesse
1820 restrizioni di \func{link}, quindi è necessario che \param{oldpath}
1821 e \param{newpath} siano nello stesso filesystem e facciano riferimento allo
1822 stesso \textit{mount point}, e che il filesystem supporti questo tipo di
1823 operazione. Qualora questo non avvenga si dovrà effettuare l'operazione in
1824 maniera non atomica copiando il file a destinazione e poi cancellando
1825 l'originale.
1826
1827 Il comportamento della funzione è diverso a seconda che si voglia rinominare
1828 un file o una directory. Se ci riferisce ad un file allora \param{newpath}, se
1829 esiste, non deve essere una directory, altrimenti si avrà un errore di
1830 \errcode{EISDIR}. Se \param{newpath} indica un file già esistente questo verrà
1831 rimpiazzato atomicamente, ma nel caso in cui \func{rename} fallisca il kernel
1832 assicura che esso non sarà toccato. I caso di sovrascrittura però potrà
1833 esistere una breve finestra di tempo in cui sia \param{oldpath}
1834 che \param{newpath} potranno fare entrambi riferimento al file che viene
1835 rinominato.
1836
1837 Se \param{oldpath} è una directory allora \param{newpath}, se esistente, deve
1838 essere una directory vuota, altrimenti si avranno gli errori \errcode{ENOTDIR}
1839 (se non è una directory) o \errcode{ENOTEMPTY} o \errcode{EEXIST} (se non è
1840 vuota). Chiaramente \param{newpath} non potrà contenere \param{oldpath} nel
1841 suo \textit{pathname}, non essendo possibile rendere una directory una
1842 sottodirectory di sé stessa, se questo fosse il caso si otterrebbe un errore
1843 di \errcode{EINVAL}.
1844
1845 Se \param{oldpath} si riferisce ad un collegamento simbolico questo sarà
1846 rinominato restando tale senza nessun effetto sul file a cui fa riferimento.
1847 Se invece \param{newpath} esiste ed è un collegamento simbolico verrà
1848 cancellato come qualunque altro file.  Infine qualora \param{oldpath}
1849 e \param{newpath} siano due nomi che già fanno riferimento allo stesso file lo
1850 standard POSIX prevede che la funzione non ritorni un errore, e semplicemente
1851 non faccia nulla, lasciando entrambi i nomi.  Linux segue questo standard,
1852 anche se, come fatto notare dal manuale della \acr{glibc}, il comportamento
1853 più ragionevole sarebbe quello di cancellare \param{oldpath}.
1854
1855 In tutti i casi si dovranno avere i permessi di scrittura nelle directory
1856 contenenti \param{oldpath} e \param{newpath}, e nel caso \param{newpath} sia
1857 una directory vuota già esistente anche su di essa (perché dovrà essere
1858 aggiornata la voce ``\texttt{..}''). Se poi le directory
1859 contenenti \param{oldpath} o \param{newpath} hanno lo \textit{sticky bit}
1860 attivo (vedi sez.~\ref{sec:file_special_perm}) si dovrà essere i proprietari
1861 dei file (o delle directory) che si vogliono rinominare, o avere i permessi di
1862 amministratore.
1863
1864
1865 \subsection{La creazione e la cancellazione delle directory} 
1866 \label{sec:file_dir_creat_rem}
1867
1868 Benché in sostanza le directory non siano altro che dei file contenenti
1869 elenchi di nomi con riferimenti ai rispettivi \textit{inode}, non è possibile
1870 trattarle come file ordinari e devono essere create direttamente dal kernel
1871 attraverso una opportuna \textit{system call}.\footnote{questo è quello che
1872   permette anche, attraverso l'uso del VFS, l'utilizzo di diversi formati per
1873   la gestione dei suddetti elenchi, dalle semplici liste a strutture complesse
1874   come alberi binari, hash, ecc. che consentono una ricerca veloce quando il
1875   numero di file è molto grande.}  La funzione di sistema usata per creare una
1876 directory è \funcd{mkdir}, ed il suo prototipo è:
1877
1878 \begin{funcproto}{
1879 \fhead{sys/stat.h}
1880 \fhead{sys/types.h}
1881 \fdecl{int mkdir(const char *dirname, mode\_t mode)}
1882 \fdesc{Crea una nuova directory.} 
1883 }
1884 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1885   caso \var{errno} assumerà uno dei valori: 
1886   \begin{errlist}
1887   \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory in
1888     cui si vuole inserire la nuova directory o di attraversamento per le
1889     directory al di sopra di essa.
1890   \item[\errcode{EEXIST}] un file o una directory o un collegamento simbolico
1891     con quel nome esiste già.
1892   \item[\errcode{EMLINK}] la directory in cui si vuole creare la nuova
1893     directory contiene troppi file; sotto Linux questo normalmente non avviene
1894     perché il filesystem standard consente la creazione di un numero di file
1895     maggiore di quelli che possono essere contenuti nel disco, ma potendo
1896     avere a che fare anche con filesystem di altri sistemi questo errore può
1897     presentarsi.
1898   \item[\errcode{ENOSPC}] non c'è abbastanza spazio sul file system per creare
1899     la nuova directory o si è esaurita la quota disco dell'utente.
1900   \end{errlist}
1901   ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG},
1902   \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EPERM},
1903   \errval{EROFS} nel loro significato generico.}
1904 \end{funcproto}
1905
1906 La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
1907 standard presenti in ogni directory (``\file{.}'' e ``\file{..}''), con il
1908 nome indicato dall'argomento \param{dirname}. 
1909
1910 I permessi di accesso (vedi sez.~\ref{sec:file_access_control}) con cui la
1911 directory viene creata sono specificati dall'argomento \param{mode}, i cui
1912 possibili valori sono riportati in tab.~\ref{tab:file_permission_const}; si
1913 tenga presente che questi sono modificati dalla maschera di creazione dei file
1914 (si veda sez.~\ref{sec:file_perm_management}).  La titolarità della nuova
1915 directory è impostata secondo quanto illustrato in
1916 sez.~\ref{sec:file_ownership_management}.
1917
1918 Come accennato in precedenza per eseguire la cancellazione di una directory è
1919 necessaria una specifica funzione di sistema, \funcd{rmdir}, il suo prototipo
1920 è:
1921
1922 \begin{funcproto}{
1923 \fhead{sys/stat.h}
1924 \fdecl{int rmdir(const char *dirname)}
1925 \fdesc{Cancella una directory.} 
1926 }
1927 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1928   caso \var{errno} assumerà uno dei valori: 
1929   \begin{errlist}
1930   \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory
1931     che contiene la directory che si vuole cancellare, o non c'è il permesso
1932     di attraversare (esecuzione) una delle directory specificate in
1933     \param{dirname}.
1934   \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o
1935     la radice di qualche processo o un \textit{mount point}.
1936   \item[\errcode{EINVAL}] si è usato ``\texttt{.}'' come ultimo componente
1937     di \param{dirname}.
1938   \item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
1939     directory, oppure la directory che contiene \param{dirname} ha lo
1940     \textit{sticky bit} impostato e non si è i proprietari della directory o
1941     non si hanno privilegi amministrativi.
1942   \end{errlist}
1943   ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG},
1944   \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errcode{ENOTEMPTY} e
1945   \errval{EROFS} nel loro significato generico.}
1946 \end{funcproto}
1947
1948
1949 La funzione cancella la directory \param{dirname}, che deve essere vuota, la
1950 directory deve cioè contenere le due voci standard ``\file{.}'' e
1951 ``\file{..}'' e niente altro.  Il nome può essere indicato con un
1952 \textit{pathname} assoluto o relativo, ma si deve fare riferimento al nome
1953 nella directory genitrice, questo significa che \textit{pathname} terminanti
1954 in ``\file{.}'' e ``\file{..}'' anche se validi in altri contesti, causeranno
1955 il fallimento della funzione.
1956
1957 Se la directory cancellata risultasse aperta in qualche processo per una
1958 lettura dei suoi contenuti (vedi sez.~\ref{sec:file_dir_read}), pur
1959 scomparendo dal filesystem e non essendo più possibile accedervi o crearvi
1960 altri file, le risorse ad essa associate verrebbero disallocate solo alla
1961 chiusura di tutti questi ulteriori riferimenti.
1962
1963
1964 \subsection{Lettura e scansione delle directory}
1965 \label{sec:file_dir_read}
1966
1967 Benché le directory alla fine non siano altro che dei file che contengono
1968 delle liste di nomi associati ai relativi \textit{inode}, per il ruolo che
1969 rivestono nella struttura del sistema non possono essere trattate come dei
1970 normali file di dati. Ad esempio, onde evitare inconsistenze all'interno del
1971 filesystem, solo il kernel può scrivere il contenuto di una directory, e non
1972 può essere un processo a inserirvi direttamente delle voci con le usuali
1973 funzioni di scrittura.
1974
1975 Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
1976 kernel, sono molte le situazioni in cui i processi necessitano di poterne
1977 leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo
1978 in sez.~\ref{sec:file_open_close} che è possibile aprire una directory come se
1979 fosse un file, anche se solo in sola lettura) in generale il formato con cui
1980 esse sono scritte può dipendere dal tipo di filesystem, tanto che, come
1981 riportato in tab.~\ref{tab:file_file_operations}, il VFS prevede una apposita
1982 funzione per la lettura delle directory.
1983
1984 \itindbeg{directory~stream}
1985
1986 Tutto questo si riflette nello standard POSIX\footnote{le funzioni erano
1987   presenti in SVr4 e 4.3BSD, la loro specifica è riportata in POSIX.1-2001.}
1988 che ha introdotto una apposita interfaccia per la lettura delle directory,
1989 basata sui cosiddetti \textit{directory stream}, chiamati così per l'analogia
1990 con i \textit{file stream} dell'interfaccia standard ANSI C che vedremo in
1991 sez.~\ref{sec:files_std_interface}. La prima funzione di questa interfaccia è
1992 \funcd{opendir}, il cui prototipo è:
1993
1994 \begin{funcproto}{
1995 \fhead{sys/types.h}
1996 \fhead{dirent.h}
1997 \fdecl{DIR *opendir(const char *dirname)}
1998 \fdesc{Apre un \textit{directory stream}.} 
1999 }
2000 {La funzione ritorna un puntatore al \textit{directory stream} in caso di
2001   successo e \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno
2002   dei valori \errval{EACCES}, \errval{EMFILE}, \errval{ENFILE},
2003   \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR} nel loro significato
2004   generico.}
2005 \end{funcproto}
2006
2007 La funzione apre un \textit{directory stream} per la directory
2008 \param{dirname}, ritornando il puntatore ad un oggetto di tipo \typed{DIR} (che
2009 è il tipo opaco usato dalle librerie per gestire i \textit{directory stream})
2010 da usare per tutte le operazioni successive, la funzione inoltre posiziona lo
2011 \textit{stream} sulla prima voce contenuta nella directory.
2012
2013 Si tenga presente che comunque la funzione opera associando il
2014 \textit{directory stream} ad un opportuno file descriptor sottostante, sul
2015 quale vengono compiute le operazioni. Questo viene sempre aperto impostando il
2016 flag di \textit{close-on-exec} (si ricordi quanto detto in
2017 sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso di
2018 esecuzione di un altro programma.
2019
2020 Nel caso in cui sia necessario conoscere il \textit{file descriptor} associato
2021 ad un \textit{directory stream} si può usare la funzione
2022 \funcd{dirfd},\footnote{questa funzione è una estensione introdotta con BSD
2023   4.3-Reno ed è presente in Linux con le libc5 (a partire dalla versione
2024   5.1.2) e con la \acr{glibc} ma non presente in POSIX fino alla revisione
2025   POSIX.1-2008, per questo per poterla utilizzare fino alla versione 2.10
2026   della \acr{glibc} era necessario definire le macro \macro{\_BSD\_SOURCE} o
2027   \macro{\_SVID\_SOURCE}, dalla versione 2.10 si possono usare anche
2028   \texttt{\macro{\_POSIX\_C\_SOURCE} >= 200809L} o
2029   \texttt{\macro{\_XOPEN\_SOURCE} >= 700}.}  il cui prototipo è:
2030
2031 \begin{funcproto}{
2032 \fhead{sys/types.h}
2033 \fhead{dirent.h}
2034 \fdecl{int dirfd(DIR *dir)}
2035 \fdesc{Legge il file descriptor associato ad un \textit{directory stream}.} 
2036 }
2037 {La funzione ritorna un valore positivo corrispondente al file descriptor in
2038   caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà
2039   uno dei valori:
2040   \begin{errlist}
2041   \item[\errcode{EINVAL}] \param{dir} non è un puntatore ad un
2042     \textit{directory stream}. 
2043   \item[\errcode{ENOTSUP}] l'implementazione non supporta l'uso di un file
2044     descriptor per la directory.
2045   \end{errlist}
2046 }
2047 \end{funcproto}
2048
2049 La funzione restituisce il file descriptor associato al \textit{directory
2050   stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
2051 funzioni che operano sui file descriptor, ad esempio si potrà usare
2052 \func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
2053 spostare su di essa la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}).
2054
2055 Viceversa se si è aperto un file descriptor corrispondente ad una directory è
2056 possibile associarvi un \textit{directory stream} con la funzione
2057 \funcd{fdopendir},\footnote{questa funzione è però disponibile solo a partire
2058   dalla versione 2.4 della \acr{glibc}, ed è stata introdotta nello standard
2059   POSIX solo a partire dalla revisione POSIX.1-2008, prima della versione 2.10
2060   della \acr{glibc} per poterla utilizzare era necessario definire la macro
2061   \macro{\_GNU\_SOURCE}, dalla versione 2.10 si possono usare anche
2062   \texttt{\macro{\_POSIX\_C\_SOURCE} >= 200809L} o \texttt{\_XOPEN\_SOURCE >=
2063     700} .}  il cui prototipo è:
2064
2065 \begin{funcproto}{
2066 \fhead{sys/types.h}
2067 \fhead{dirent.h}
2068 \fdecl{DIR *fdopendir(int fd)}
2069 \fdesc{Associa un \textit{directory stream} ad un file descriptor.} 
2070 }
2071 {La funzione ritorna un puntatore al \textit{directory stream} in caso di
2072   successo e \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno
2073   dei valori \errval{EBADF} o \errval{ENOMEM} nel loro significato generico.}
2074 \end{funcproto}
2075
2076 La funzione è identica a \func{opendir}, ma ritorna un \textit{directory
2077   stream} facendo riferimento ad un file descriptor \param{fd} che deve essere
2078 stato aperto in precedenza; la funzione darà un errore qualora questo non
2079 corrisponda ad una directory. L'uso di questa funzione permette di rispondere
2080 agli stessi requisiti delle funzioni ``\textit{at}'' che vedremo in
2081 sez.~\ref{sec:file_openat}.
2082
2083 Una volta utilizzata il file descriptor verrà usato internamente dalle
2084 funzioni che operano sul \textit{directory stream} e non dovrà essere più
2085 utilizzato all'interno del proprio programma. In particolare dovrà essere
2086 chiuso attraverso il \textit{directory stream} con \func{closedir} e non
2087 direttamente. Si tenga presente inoltre che \func{fdopendir} non modifica lo
2088 stato di un eventuale flag di \textit{close-on-exec}, che pertanto dovrà
2089 essere impostato esplicitamente in fase di apertura del file descriptor.
2090
2091 Una volta che si sia aperto un \textit{directory stream} la lettura del
2092 contenuto della directory viene effettuata attraverso la funzione
2093 \funcd{readdir}, il cui prototipo è:
2094
2095 \begin{funcproto}{
2096 \fhead{sys/types.h}
2097 \fhead{dirent.h}
2098 \fdecl{struct dirent *readdir(DIR *dir)}
2099 \fdesc{Legge una voce dal \textit{directory stream}.} 
2100 }
2101 {La funzione ritorna il puntatore alla struttura contenente i dati in caso di
2102   successo e \val{NULL} per un errore o se si è raggiunta la fine dello
2103   \textit{stream}. Il solo codice di errore restituito in \var{errno} è
2104   \errval{EBADF} qualora \param{dir} non indichi un \textit{directory stream}
2105   valido.}
2106 \end{funcproto}
2107
2108 La funzione legge la voce corrente nella directory, posizionandosi sulla voce
2109 successiva. Pertanto se si vuole leggere l'intero contenuto di una directory
2110 occorrerà ripetere l'esecuzione della funzione fintanto che non si siano
2111 esaurite tutte le voci in essa presenti, che viene segnalata dalla
2112 restituzione di \val{NULL} come valore di ritorno. Si può distinguere questa
2113 condizione da un errore in quanto in questo caso \var{errno} non verrebbe
2114 modificata.
2115
2116 I dati letti da \func{readdir} vengono memorizzati in una struttura
2117 \struct{dirent}, la cui definizione è riportata in
2118 fig.~\ref{fig:file_dirent_struct}.\footnote{la definizione è quella usata da
2119   Linux, che si trova nel file \file{/usr/include/bits/dirent.h}, essa non
2120   contempla la presenza del campo \var{d\_namlen} che indica la lunghezza del
2121   nome del file.} La funzione non è rientrante e restituisce il puntatore ad
2122 una struttura allocata staticamente, che viene sovrascritta tutte le volte che
2123 si ripete la lettura di una voce sullo stesso \textit{directory stream}.
2124
2125 Di questa funzione esiste anche una versione rientrante,
2126 \funcd{readdir\_r},\footnote{per usarla è necessario definire una qualunque
2127   delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
2128   \macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
2129   \macro{\_POSIX\_SOURCE}.} che non usa una struttura allocata staticamente, e
2130 può essere utilizzata anche con i \textit{thread}, il suo prototipo è:
2131
2132 \begin{funcproto}{
2133 \fhead{sys/types.h}
2134 \fhead{dirent.h}
2135 \fdecl{int readdir\_r(DIR *dir, struct dirent *entry, struct dirent **result)}
2136 \fdesc{Legge una voce dal \textit{directory stream}.} 
2137 }
2138 {La funzione ritorna $0$ in caso di successo ed un numero positivo per un
2139   errore, nel qual caso \var{errno} assumerà gli stessi valori di
2140   \func{readdir}.} 
2141 \end{funcproto}
2142
2143 La funzione restituisce in \param{result} come \textit{value result argument}
2144 l'indirizzo della struttura \struct{dirent} dove sono stati salvati i dati,
2145 che deve essere allocata dal chiamante, ed il cui indirizzo deve essere
2146 indicato con l'argomento \param{entry}.  Se si è raggiunta la fine del
2147 \textit{directory stream} invece in \param{result} viene restituito il valore
2148 \val{NULL}.
2149
2150 \begin{figure}[!htb]
2151   \footnotesize \centering
2152   \begin{minipage}[c]{0.8\textwidth}
2153     \includestruct{listati/dirent.c}
2154   \end{minipage} 
2155   \normalsize 
2156   \caption{La struttura \structd{dirent} per la lettura delle informazioni dei 
2157     file.}
2158   \label{fig:file_dirent_struct}
2159 \end{figure}
2160
2161 % Lo spazio per la \struct{dirent} dove vengono restituiti i dati della
2162 % directory deve essere allocato a cura del chiamante, dato che la dimensione
2163
2164
2165 I vari campi di \struct{dirent} contengono le informazioni relative alle voci
2166 presenti nella directory. Sia BSD che SVr4 che POSIX.1-2001\footnote{il
2167   vecchio standard POSIX prevedeva invece solo la presenza del campo
2168   \var{d\_fileno}, identico \var{d\_ino}, che in Linux era definito come alias
2169   di quest'ultimo, mentre il campo \var{d\_name} era considerato dipendente
2170   dall'implementazione.}  prevedono che siano sempre presenti il campo
2171 \var{d\_name}, che contiene il nome del file nella forma di una stringa
2172 terminata da uno zero, ed il campo \var{d\_ino}, che contiene il numero di
2173 \textit{inode} cui il file è associato e corrisponde al campo \var{st\_ino} di
2174 \struct{stat}.  La presenza di ulteriori campi opzionali oltre i due citati è
2175 segnalata dalla definizione di altrettante macro nella forma
2176 \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è il nome del relativo
2177 campo. Come si può evincere da fig.~\ref{fig:file_dirent_struct} nel caso di
2178 Linux sono pertanto definite le macro \macrod{\_DIRENT\_HAVE\_D\_TYPE},
2179 \macrod{\_DIRENT\_HAVE\_D\_OFF} e \macrod{\_DIRENT\_HAVE\_D\_RECLEN}, mentre non
2180 è definita la macro \macrod{\_DIRENT\_HAVE\_D\_NAMLEN}.
2181
2182 Dato che possono essere presenti campi opzionali e che lo standard
2183 POSIX.1-2001 non specifica una dimensione definita per il nome dei file (che
2184 può variare a seconda del filesystem), ma solo un limite superiore pari a
2185 \const{NAME\_MAX} (vedi tab.~\ref{tab:sys_file_macro}), in generale per
2186 allocare una struttura \struct{dirent} in maniera portabile occorre eseguire
2187 un calcolo per ottenere le dimensioni appropriate per il proprio
2188 sistema.\footnote{in SVr4 la lunghezza del campo è definita come
2189   \code{NAME\_MAX+1} che di norma porta al valore di 256 byte usato anche in
2190   fig.~\ref{fig:file_dirent_struct}.} Lo standard però richiede che il campo
2191 \var{d\_name} sia sempre l'ultimo della struttura, questo ci consente di
2192 ottenere la dimensione della prima parte con la macro di utilità generica
2193 \macro{offsetof}, che si può usare con il seguente prototipo:
2194
2195 {\centering
2196 \vspace{3pt}
2197 \begin{funcbox}{
2198 \fhead{stddef.h}
2199 \fdecl{size\_t \macrod{offsetof}(type, member)}
2200 \fdesc{Restituisce la posizione del campo \param{member} nella
2201   struttura \param{type}.}
2202
2203 \end{funcbox}
2204 }
2205
2206 Ottenuta allora con \code{offsetof(struct dirent, d\_name)} la dimensione
2207 della parte iniziale della struttura, basterà sommarci la dimensione massima
2208 dei nomi dei file nel filesystem che si sta usando, che si può ottenere
2209 attraverso la funzione \func{pathconf} (per la quale si rimanda a
2210 sez.~\ref{sec:sys_file_limits}) più un ulteriore carattere per la terminazione
2211 della stringa.
2212
2213 Per quanto riguarda il significato dei campi opzionali, il campo \var{d\_type}
2214 indica il tipo di file (se \textit{fifo}, directory, collegamento simbolico,
2215 ecc.), e consente di evitare una successiva chiamata a \func{lstat} (vedi
2216 sez.~\ref{sec:file_stat}) per determinarlo. I suoi possibili valori sono
2217 riportati in tab.~\ref{tab:file_dtype_macro}. Si tenga presente che questo
2218 valore è disponibile solo per i filesystem che ne supportano la restituzione
2219 (fra questi i più noti sono \textsl{btrfs}, \textsl{ext2}, \textsl{ext3}, e
2220 \textsl{ext4}), per gli altri si otterrà sempre il valore
2221 \const{DT\_UNKNOWN}.\footnote{inoltre fino alla versione 2.1 della
2222   \acr{glibc}, pur essendo il campo \var{d\_type} presente, il suo uso non era
2223   implementato, e veniva restituito comunque il valore \const{DT\_UNKNOWN}.}
2224
2225 \begin{table}[htb]
2226   \centering
2227   \footnotesize
2228   \begin{tabular}[c]{|l|l|}
2229     \hline
2230     \textbf{Valore} & \textbf{Tipo di file} \\
2231     \hline
2232     \hline
2233     \constd{DT\_UNKNOWN} & Tipo sconosciuto.\\
2234     \constd{DT\_REG}     & File normale.\\
2235     \constd{DT\_DIR}     & Directory.\\
2236     \constd{DT\_LNK}     & Collegamento simbolico.\\
2237     \constd{DT\_FIFO}    & \textit{Fifo}.\\
2238     \constd{DT\_SOCK}    & Socket.\\
2239     \constd{DT\_CHR}     & Dispositivo a caratteri.\\
2240     \constd{DT\_BLK}     & Dispositivo a blocchi.\\
2241     \hline    
2242   \end{tabular}
2243   \caption{Costanti che indicano i vari tipi di file nel campo \var{d\_type}
2244     della struttura \struct{dirent}.}
2245   \label{tab:file_dtype_macro}
2246 \end{table}
2247
2248 Per la conversione da e verso l'analogo valore mantenuto dentro il campo
2249 \var{st\_mode} di \struct{stat} (vedi fig.~\ref{fig:file_stat_struct}) sono
2250 definite anche due macro di conversione, \macro{IFTODT} e \macro{DTTOIF}:
2251
2252 {\centering
2253 \vspace{3pt}
2254 \begin{funcbox}{
2255 \fhead{dirent.h}
2256 \fdecl{int \macrod{IFTODT}(mode\_t MODE)}
2257 \fdesc{Converte il tipo di file dal formato di \var{st\_mode} a quello di
2258   \var{d\_type}.}
2259 \fdecl{mode\_t \macrod{DTTOIF}(int DTYPE)}
2260 \fdesc{Converte il tipo di file dal formato di \var{d\_type} a quello di
2261   \var{st\_mode}.}  
2262
2263 \end{funcbox}
2264 }
2265
2266 Il campo \var{d\_off} contiene invece la posizione della voce successiva della
2267 directory, mentre il campo \var{d\_reclen} la lunghezza totale della voce
2268 letta. Con questi due campi diventa possibile, determinando la posizione delle
2269 varie voci, spostarsi all'interno dello \textit{stream} usando la funzione
2270 \funcd{seekdir},\footnote{sia questa funzione che \func{telldir}, sono
2271   estensioni prese da BSD, ed introdotte nello standard POSIX solo a partire
2272   dalla revisione POSIX.1-2001, per poterle utilizzare deve essere definita
2273   una delle macro \macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE} o
2274   \macro{\_SVID\_SOURCE}.} il cui prototipo è:
2275
2276 \begin{funcproto}{
2277 \fhead{dirent.h}
2278 \fdecl{void seekdir(DIR *dir, off\_t offset)}
2279 \fdesc{Cambia la posizione all'interno di un \textit{directory stream}.} 
2280 }
2281 {La funzione non ritorna niente e non imposta errori.}
2282 \end{funcproto}
2283
2284 La funzione non ritorna nulla e non segnala errori, è però necessario che il
2285 valore dell'argomento \param{offset} sia valido per lo
2286 \textit{stream} \param{dir}; esso pertanto deve essere stato ottenuto o dal
2287 valore di \var{d\_off} di \struct{dirent} o dal valore restituito dalla
2288 funzione \funcd{telldir}, che legge la posizione corrente; il cui prototipo
2289 è:\footnote{prima della \acr{glibc} 2.1.1 la funzione restituiva un valore di
2290   tipo \type{off\_t}, sostituito a partire dalla versione 2.1.2 da \ctyp{long}
2291   per conformità a POSIX.1-2001.}
2292
2293 \begin{funcproto}{
2294 \fhead{dirent.h}
2295 \fdecl{long telldir(DIR *dir)}
2296 \fdesc{Ritorna la posizione corrente in un \textit{directory stream}.} 
2297 }
2298 {La funzione ritorna la posizione corrente nello \textit{stream} (un numero
2299   positivo) in caso di successo e $-1$ per un errore, nel qual caso
2300   \var{errno} assume solo il valore di \errval{EBADF}, corrispondente ad un
2301   valore errato per \param{dir}.  }
2302 \end{funcproto}
2303
2304 La sola funzione di posizionamento per un \textit{directory stream} prevista
2305 originariamente dallo standard POSIX è \funcd{rewinddir}, che riporta la
2306 posizione a quella iniziale; il suo prototipo è:
2307
2308 \begin{funcproto}{
2309 \fhead{sys/types.h}
2310 \fhead{dirent.h}
2311 \fdecl{void rewinddir(DIR *dir)}
2312 \fdesc{Si posiziona all'inizio di un \textit{directory stream}.} 
2313 }
2314 {La funzione non ritorna niente e non imposta errori.}
2315 \end{funcproto}
2316
2317 Una volta completate le operazioni si può chiudere il \textit{directory
2318   stream}, ed il file descriptor ad esso associato, con la funzione
2319 \funcd{closedir}, il cui prototipo è:
2320
2321 \begin{funcproto}{
2322 \fhead{sys/types.h}
2323 \fhead{dirent.h}
2324 \fdecl{int closedir(DIR *dir)}
2325 \fdesc{Chiude un \textit{directory stream}.} 
2326 }
2327 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2328   caso \var{errno} assume solo il valore \errval{EBADF}.}
2329 \end{funcproto}
2330
2331 A parte queste funzioni di base in BSD 4.3 venne introdotta un'altra funzione
2332 che permette di eseguire una scansione completa, con tanto di ricerca ed
2333 ordinamento, del contenuto di una directory; la funzione è
2334 \funcd{scandir}\footnote{in Linux questa funzione è stata introdotta fin dalle
2335   \acr{libc4} e richiede siano definite le macro \macro{\_BSD\_SOURCE} o
2336   \macro{\_SVID\_SOURCE}.} ed il suo prototipo è:
2337
2338 \begin{funcproto}{
2339 \fhead{dirent.h}
2340 \fdecl{int scandir(const char *dir, struct dirent ***namelist, \\
2341 \phantom{int scandir(}int(*filter)(const struct dirent *), \\
2342 \phantom{int scandir(}int(*compar)(const struct dirent **, const struct dirent **))}
2343 \fdesc{Esegue una scansione di un \textit{directory stream}.} 
2344 }
2345 {La funzione ritorna il numero di voci trovate in caso di successo e $-1$ per
2346   un errore, nel qual caso \var{errno} può assumere solo il valore
2347   \errval{ENOMEM}.}
2348 \end{funcproto}
2349
2350 Al solito, per la presenza fra gli argomenti di due puntatori a funzione, il
2351 prototipo non è molto comprensibile; queste funzioni però sono quelle che
2352 controllano rispettivamente la selezione di una voce, passata con
2353 l'argomento \param{filter}, e l'ordinamento di tutte le voci selezionate,
2354 specificata dell'argomento \param{compar}.
2355
2356 La funzione legge tutte le voci della directory indicata dall'argomento
2357 \param{dir}, passando un puntatore a ciascuna di esse (una struttura
2358 \struct{dirent}) come argomento della funzione di selezione specificata da
2359 \param{filter}; se questa ritorna un valore diverso da zero il puntatore viene
2360 inserito in un vettore che viene allocato dinamicamente con \func{malloc}.
2361 Qualora si specifichi un valore \val{NULL} per l'argomento \param{filter} non
2362 viene fatta nessuna selezione e si ottengono tutte le voci presenti.
2363
2364 Le voci selezionate possono essere riordinate tramite \funcm{qsort}, le
2365 modalità del riordinamento possono essere personalizzate usando la funzione
2366 \param{compar} come criterio di ordinamento di \funcm{qsort}, la funzione
2367 prende come argomenti le due strutture \struct{dirent} da confrontare
2368 restituendo un valore positivo, nullo o negativo per indicarne l'ordinamento;
2369 alla fine l'indirizzo della lista ordinata dei puntatori alle strutture
2370 \struct{dirent} viene restituito nell'argomento
2371 \param{namelist}.\footnote{la funzione alloca automaticamente la lista, e
2372   restituisce, come \textit{value result argument}, l'indirizzo della stessa;
2373   questo significa che \param{namelist} deve essere dichiarato come
2374   \code{struct dirent **namelist} ed alla funzione si deve passare il suo
2375   indirizzo.}
2376
2377 \itindend{directory~stream}
2378
2379 Per l'ordinamento, vale a dire come valori possibili per l'argomento
2380 \param{compar}, sono disponibili due funzioni predefinite, \funcd{alphasort} e
2381 \funcd{versionsort}, i cui prototipi sono:
2382
2383 \begin{funcproto}{
2384 \fhead{dirent.h}
2385 \fdecl{int alphasort(const void *a, const void *b)}
2386 \fdecl{int versionsort(const void *a, const void *b)}
2387 \fdesc{Riordinano le voci di \textit{directory stream}.} 
2388 }
2389 {Le funzioni restituiscono un valore minore, uguale o maggiore di zero qualora
2390   il primo argomento sia rispettivamente minore, uguale o maggiore del secondo
2391   e non forniscono errori.}
2392 \end{funcproto}
2393
2394 La funzione \func{alphasort} deriva da BSD ed è presente in Linux fin dalle
2395 \acr{libc4}\footnote{la versione delle \acr{libc4} e \acr{libc5} usa però come
2396   argomenti dei puntatori a delle strutture \struct{dirent}; la glibc usa il
2397   prototipo originario di BSD, mostrato anche nella definizione, che prevede
2398   puntatori a \ctyp{void}.} e deve essere specificata come argomento
2399 \param{compar} per ottenere un ordinamento alfabetico secondo il valore del
2400 campo \var{d\_name} delle varie voci. La \acr{glibc} prevede come
2401 estensione\footnote{la \acr{glibc}, a partire dalla versione 2.1, effettua
2402   anche l'ordinamento alfabetico tenendo conto delle varie localizzazioni,
2403   usando \funcm{strcoll} al posto di \funcm{strcmp}.} anche
2404 \func{versionsort}, che ordina i nomi tenendo conto del numero di versione,
2405 cioè qualcosa per cui \texttt{file10} viene comunque dopo \texttt{file4}.
2406
2407 \begin{figure}[!htbp]
2408   \footnotesize \centering
2409   \begin{minipage}[c]{\codesamplewidth}
2410     \includecodesample{listati/my_ls.c}
2411   \end{minipage}
2412   \caption{Esempio di codice per eseguire la lista dei file contenuti in una
2413     directory.} 
2414   \label{fig:file_my_ls}
2415 \end{figure}
2416
2417 Un semplice esempio dell'uso di queste funzioni è riportato in
2418 fig.~\ref{fig:file_my_ls}, dove si è riportata la sezione principale di un
2419 programma che, usando la funzione di scansione illustrata in
2420 fig.~\ref{fig:file_dirscan}, stampa i nomi dei file contenuti in una directory
2421 e la relativa dimensione, in sostanza una versione semplificata del comando
2422 \cmd{ls}.
2423
2424 Il programma è estremamente semplice; in fig.~\ref{fig:file_my_ls} si è omessa
2425 la parte di gestione delle opzioni, che prevede solo l'uso di una funzione per
2426 la stampa della sintassi, anch'essa omessa, ma il codice completo può essere
2427 trovato coi sorgenti allegati alla guida nel file \file{myls.c}.
2428
2429 In sostanza tutto quello che fa il programma, dopo aver controllato
2430 (\texttt{\small 12-15}) di avere almeno un argomento, che indicherà la
2431 directory da esaminare, è chiamare (\texttt{\small 16}) la funzione
2432 \myfunc{dir\_scan} per eseguire la scansione, usando la funzione \code{do\_ls}
2433 (\texttt{\small 22-29}) per fare tutto il lavoro.
2434
2435 Quest'ultima si limita (\texttt{\small 26}) a chiamare \func{stat} sul file
2436 indicato dalla directory entry passata come argomento (il cui nome è appunto
2437 \var{direntry->d\_name}), memorizzando in una opportuna struttura \var{data} i
2438 dati ad esso relativi, per poi provvedere (\texttt{\small 27}) a stampare il
2439 nome del file e la dimensione riportata in \var{data}.
2440
2441 Dato che la funzione verrà chiamata all'interno di \myfunc{dir\_scan} per ogni
2442 voce presente questo è sufficiente a stampare la lista completa dei file e
2443 delle relative dimensioni. Si noti infine come si restituisca sempre 0 come
2444 valore di ritorno per indicare una esecuzione senza errori.
2445
2446 \begin{figure}[!htbp]
2447   \footnotesize \centering
2448   \begin{minipage}[c]{\codesamplewidth}
2449     \includecodesample{listati/dir_scan.c}
2450   \end{minipage}
2451   \caption{Codice della funzione di scansione di una directory contenuta nel
2452     file \file{dir\_scan.c}.} 
2453   \label{fig:file_dirscan}
2454 \end{figure}
2455
2456 Tutto il grosso del lavoro è svolto dalla funzione \myfunc{dir\_scan},
2457 riportata in fig.~\ref{fig:file_dirscan}. La funzione è volutamente generica e
2458 permette di eseguire una funzione, passata come secondo argomento, su tutte le
2459 voci di una directory.  La funzione inizia con l'aprire (\texttt{\small
2460   18-22}) uno \textit{stream} sulla directory passata come primo argomento,
2461 stampando un messaggio in caso di errore.
2462
2463 Il passo successivo (\texttt{\small 23-24}) è cambiare directory di lavoro
2464 (vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni
2465 \func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
2466 \func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
2467 (\texttt{\small 26-30}) sulle singole voci dello \textit{stream} ci si trovi
2468 all'interno della directory.\footnote{questo è essenziale al funzionamento
2469   della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo
2470   \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
2471   struttura \struct{dirent} sono sempre relativi alla directory in questione,
2472   e senza questo posizionamento non si sarebbe potuto usare \func{stat} per
2473   ottenere le dimensioni.}
2474
2475 Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
2476 alla funzione passata come secondo argomento, il ciclo di scansione della
2477 directory è molto semplice; si legge una voce alla volta (\texttt{\small 26})
2478 all'interno di una istruzione di \code{while} e fintanto che si riceve una
2479 voce valida, cioè un puntatore diverso da \val{NULL}, si esegue
2480 (\texttt{\small 27}) la funzione di elaborazione \var{compare} (che nel nostro
2481 caso sarà \code{do\_ls}), ritornando con un codice di errore (\texttt{\small
2482   28}) qualora questa presenti una anomalia, identificata da un codice di
2483 ritorno negativo. Una volta terminato il ciclo la funzione si conclude con la
2484 chiusura (\texttt{\small 32}) dello \textit{stream}\footnote{nel nostro caso,
2485   uscendo subito dopo la chiamata, questo non servirebbe, in generale però
2486   l'operazione è necessaria, dato che la funzione può essere invocata molte
2487   volte all'interno dello stesso processo, per cui non chiudere i
2488   \textit{directory stream} comporterebbe un consumo progressivo di risorse,
2489   con conseguente rischio di esaurimento delle stesse.} e la restituzione
2490 (\texttt{\small 32}) del codice di operazioni concluse con successo.
2491
2492
2493
2494 \subsection{La directory di lavoro}
2495 \label{sec:file_work_dir}
2496
2497 \index{directory~di~lavoro|(} 
2498
2499 Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
2500 directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
2501   della sua \kstruct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
2502   precisamente nel campo \texttt{pwd} della sotto-struttura
2503   \kstruct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
2504 \textsl{directory di lavoro} (in inglese \textit{current working directory}).
2505 La directory di lavoro è quella da cui si parte quando un \textit{pathname} è
2506 espresso in forma relativa, dove il ``\textsl{relativa}'' fa riferimento
2507 appunto a questa directory.
2508
2509 Quando un utente effettua il login, questa directory viene impostata alla
2510 \textit{home directory} del suo account. Il comando \cmd{cd} della shell
2511 consente di cambiarla a piacere, spostandosi da una directory ad un'altra, il
2512 comando \cmd{pwd} la stampa sul terminale.  Siccome la directory di lavoro
2513 resta la stessa quando viene creato un processo figlio (vedi
2514 sez.~\ref{sec:proc_fork}), la directory di lavoro della shell diventa anche la
2515 directory di lavoro di qualunque comando da essa lanciato.
2516
2517 Dato che è il kernel che tiene traccia per ciascun processo
2518 dell'\textit{inode} della directory di lavoro, per ottenerne il
2519 \textit{pathname} occorre usare una apposita funzione,
2520 \funcd{getcwd},\footnote{con Linux \func{getcwd} è una \textit{system call}
2521   dalla versione 2.1.9, in precedenza il valore doveva essere ottenuto tramite
2522   il filesystem \texttt{/proc} da \procfile{/proc/self/cwd}.} il cui prototipo
2523 è:
2524
2525 \begin{funcproto}{
2526 \fhead{unistd.h}
2527 \fdecl{char *getcwd(char *buffer, size\_t size)}
2528 \fdesc{Legge il \textit{pathname} della directory di lavoro corrente.} 
2529 }
2530 {La funzione ritorna il puntatore a \param{buffer} in caso di successo e
2531   \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno dei valori: 
2532   \begin{errlist}
2533   \item[\errcode{EACCES}] manca il permesso di lettura o di attraversamento  su
2534     uno dei componenti del \textit{pathname} (cioè su una delle directory
2535     superiori alla corrente).
2536   \item[\errcode{EINVAL}] l'argomento \param{size} è zero e \param{buffer} non
2537     è nullo.
2538   \item[\errcode{ENOENT}] la directory di lavoro è stata eliminata. 
2539   \item[\errcode{ERANGE}] l'argomento \param{size} è più piccolo della
2540     lunghezza del \textit{pathname}. 
2541   \end{errlist}
2542   ed inoltre \errcode{EFAULT} nel suo significato generico.}
2543 \end{funcproto}
2544
2545 La funzione restituisce il \textit{pathname} completo della directory di
2546 lavoro corrente nella stringa puntata da \param{buffer}, che deve essere
2547 precedentemente allocata, per una dimensione massima di \param{size}.  Il
2548 buffer deve essere sufficientemente largo da poter contenere il
2549 \textit{pathname} completo più lo zero di terminazione della stringa. Qualora
2550 esso ecceda le dimensioni specificate con \param{size} la funzione restituisce
2551 un errore.
2552
2553 Si può anche specificare un puntatore nullo come
2554 \param{buffer},\footnote{questa è un'estensione allo standard POSIX.1,
2555   supportata da Linux e dalla \acr{glibc}.} nel qual caso la stringa sarà
2556 allocata automaticamente per una dimensione pari a \param{size} qualora questa
2557 sia diversa da zero, o della lunghezza esatta del \textit{pathname}
2558 altrimenti. In questo caso ci si deve ricordare di disallocare la stringa con
2559 \func{free} una volta cessato il suo utilizzo.
2560
2561 Un uso comune di \func{getcwd} è quello di salvarsi la directory di lavoro
2562 all'avvio del programma per poi potervi tornare in un tempo successivo, un
2563 metodo alternativo più veloce, se non si è a corto di file descriptor, è
2564 invece quello di aprire all'inizio la directory corrente (vale a dire
2565 ``\texttt{.}'') e tornarvi in seguito con \func{fchdir}.
2566
2567 Di questa funzione esiste una versione alternativa per compatibilità
2568 all'indietro con BSD, \funcm{getwd}, che non prevede l'argomento \param{size}
2569 e quindi non consente di specificare la dimensione di \param{buffer} che
2570 dovrebbe essere allocato in precedenza ed avere una dimensione sufficiente
2571 (per BSD maggiore \const{PATH\_MAX}, che di solito 256 byte, vedi
2572 sez.~\ref{sec:sys_limits}). Il problema è che su Linux non esiste una
2573 dimensione superiore per la lunghezza di un \textit{pathname}, per cui non è
2574 detto che il buffer sia sufficiente a contenere il nome del file, e questa è
2575 la ragione principale per cui questa funzione è deprecata, e non la tratteremo.
2576
2577 Una seconda funzione usata per ottenere la directory di lavoro è
2578 \funcm{get\_current\_dir\_name},\footnote{la funzione è una estensione GNU e
2579   presente solo nella \acr{glibc}.} che non prende nessun argomento ed è
2580 sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la differenza
2581 che se disponibile essa ritorna il valore della variabile di ambiente
2582 \envvar{PWD}, che essendo costruita dalla shell può contenere un
2583 \textit{pathname} comprendente anche dei collegamenti simbolici. Usando
2584 \func{getcwd} infatti, essendo il \textit{pathname} ricavato risalendo
2585 all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio
2586 attraverso eventuali collegamenti simbolici.
2587
2588 Per cambiare la directory di lavoro si può usare la funzione di sistema
2589 \funcd{chdir}, equivalente del comando di shell \cmd{cd}, il cui nome sta
2590 appunto per \textit{change directory}, il suo prototipo è:
2591
2592 \begin{funcproto}{
2593 \fhead{unistd.h}
2594 \fdecl{int chdir(const char *pathname)}
2595 \fdesc{Cambia la directory di lavoro per \textit{pathname}.} 
2596 }
2597 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2598   caso \var{errno} assumerà uno dei valori: 
2599   \begin{errlist}
2600   \item[\errcode{EACCES}] manca il permesso di ricerca su uno dei componenti
2601     di \param{pathname}.
2602   \item[\errcode{ENOTDIR}] non si è specificata una directory.
2603   \end{errlist}
2604   ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
2605   \errval{ENAMETOOLONG}, \errval{ENOENT} e \errval{ENOMEM} nel loro
2606   significato generico.}
2607 \end{funcproto}
2608
2609 La funzione cambia la directory di lavoro in \param{pathname} ed
2610 ovviamente \param{pathname} deve indicare una directory per la quale si hanno
2611 i permessi di accesso.
2612
2613 Dato che ci si può riferire ad una directory anche tramite un file descriptor,
2614 per cambiare directory di lavoro è disponibile anche la funzione di sistema
2615 \funcd{fchdir}, il cui prototipo è:
2616
2617 \begin{funcproto}{
2618 \fhead{unistd.h}
2619 \fdecl{int fchdir(int fd)}
2620 \fdesc{Cambia la directory di lavoro per file descriptor.} 
2621 }
2622 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2623   caso \var{errno} assumerà i valori \errval{EBADF} o \errval{EACCES} nel loro
2624   significato generico.}
2625 \end{funcproto}
2626
2627 La funzione è identica a \func{chdir}, ma prende come argomento un file
2628 descriptor \param{fd} invece di un \textit{pathname}. Anche in questo
2629 caso \param{fd} deve essere un file descriptor valido che fa riferimento ad
2630 una directory. Inoltre l'unico errore di accesso possibile (tutti gli altri
2631 sarebbero occorsi all'apertura di \param{fd}), è quello in cui il processo non
2632 ha il permesso di attraversamento alla directory specificata da \param{fd}.
2633
2634 \index{directory~di~lavoro|)} 
2635
2636
2637 \subsection{La creazione dei \textsl{file speciali}}
2638 \label{sec:file_mknod}
2639
2640 \index{file!di~dispositivo|(} 
2641 \index{file!speciali|(} 
2642
2643 Finora abbiamo parlato esclusivamente di file, directory e collegamenti
2644 simbolici, ma in sez.~\ref{sec:file_file_types} abbiamo visto che il sistema
2645 prevede anche degli altri tipi di file, che in genere vanno sotto il nome
2646 generico di \textsl{file speciali}, come i file di dispositivo, le \textit{fifo} ed i
2647 socket.
2648
2649 La manipolazione delle caratteristiche di questi file speciali, il cambiamento
2650 di nome o la loro cancellazione può essere effettuata con le stesse funzioni
2651 che operano sugli altri file, ma quando li si devono creare sono necessarie,
2652 come per le directory, delle funzioni apposite. La prima di queste è la
2653 funzione di sistema \funcd{mknod}, il cui prototipo è:
2654
2655 \begin{funcproto}{
2656 \fhead{sys/types.h}
2657 \fhead{sys/stat.h}
2658 \fhead{fcntl.h}
2659 \fhead{unistd.h}
2660 \fdecl{int mknod(const char *pathname, mode\_t mode, dev\_t dev)}
2661 \fdesc{Crea un file speciale sul filesystem.} 
2662 }
2663 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2664   caso \var{errno} assumerà uno dei valori: 
2665   \begin{errlist}
2666   \item[\errcode{EEXIST}] \param{pathname} esiste già o è un collegamento
2667     simbolico. 
2668   \item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
2669     \textit{fifo}, un socket o un dispositivo.
2670   \item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare
2671     l'\texttt{inode}, o il filesystem su cui si è cercato di
2672     creare \param{pathname} non supporta l'operazione.
2673   \end{errlist}
2674   ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{ELOOP},
2675   \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOSPC},
2676   \errval{ENOTDIR} e \errval{EROFS} nel loro significato generico.}
2677 \end{funcproto}
2678
2679 La funzione permette di creare un \textit{inode} di tipo generico sul
2680 filesystem, e viene in genere utilizzata per creare i file di dispositivo, ma
2681 si può usare anche per creare qualunque tipo di file speciale ed anche file
2682 regolari. L'argomento \param{mode} specifica sia il tipo di file che si vuole
2683 creare che i relativi permessi, secondo i valori riportati in
2684 tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR aritmetico. I
2685 permessi sono comunque modificati nella maniera usuale dal valore di
2686 \textit{umask} (si veda sez.~\ref{sec:file_perm_management}).
2687
2688 Per il tipo di file può essere specificato solo uno fra i seguenti valori:
2689 \const{S\_IFREG} per un file regolare (che sarà creato vuoto),
2690 \const{S\_IFBLK} per un dispositivo a blocchi, \const{S\_IFCHR} per un
2691 dispositivo a caratteri, \const{S\_IFSOCK} per un socket e \const{S\_IFIFO}
2692 per una \textit{fifo};\footnote{con Linux la funzione non può essere usata per
2693   creare directory o collegamenti simbolici, si dovranno usare le funzioni
2694   \func{mkdir} e \func{symlink} a questo dedicate.} un valore diverso
2695 comporterà l'errore \errcode{EINVAL}. Inoltre \param{pathname} non deve
2696 esistere, neanche come collegamento simbolico.
2697
2698 Qualora si sia specificato in \param{mode} un file di dispositivo (vale a dire
2699 o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere
2700 usato per indicare a quale dispositivo si fa riferimento, altrimenti il suo
2701 valore verrà ignorato.  Solo l'amministratore può creare un file di
2702 dispositivo usando questa funzione (il processo deve avere la capacità
2703 \const{CAP\_MKNOD}), ma in Linux\footnote{questo è un comportamento specifico
2704   di Linux, la funzione non è prevista dallo standard POSIX.1 originale,
2705   mentre è presente in SVr4 e 4.4BSD, ma esistono differenze nei comportamenti
2706   e nei codici di errore, tanto che questa è stata introdotta in POSIX.1-2001
2707   con una nota che la definisce portabile solo quando viene usata per creare
2708   delle \textit{fifo}, ma comunque deprecata essendo utilizzabile a tale scopo
2709   la specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di
2710 una \textit{fifo} o di un socket è consentito anche agli utenti normali.
2711
2712 I nuovi \textit{inode} creati con \func{mknod} apparterranno al proprietario e
2713 al gruppo del processo (usando \ids{UID} e \ids{GID} del gruppo effettivo) che
2714 li ha creati a meno non sia presente il bit \acr{sgid} per la directory o sia
2715 stata attivata la semantica BSD per il filesystem (si veda
2716 sez.~\ref{sec:file_ownership_management}) in cui si va a creare
2717 l'\textit{inode}, nel qual caso per il gruppo verrà usato il \ids{GID} del
2718 proprietario della directory.
2719
2720 \itindbeg{major~number}
2721 \itindbeg{minor~number}
2722
2723 Nella creazione di un file di dispositivo occorre poi specificare
2724 correttamente il valore di \param{dev}; questo infatti è di tipo
2725 \type{dev\_t}, che è un tipo primitivo (vedi
2726 tab.~\ref{tab:intro_primitive_types}) riservato per indicare un
2727 \textsl{numero} di dispositivo. Il kernel infatti identifica ciascun
2728 dispositivo con un valore numerico, originariamente questo era un intero a 16
2729 bit diviso in due parti di 8 bit chiamate rispettivamente \textit{major
2730   number} e \textit{minor number}, che sono poi i due numeri mostrati dal
2731 comando \texttt{ls -l} al posto della dimensione quando lo si esegue su un
2732 file di dispositivo.
2733
2734 Il \textit{major number} identifica una classe di dispositivi (ad esempio la
2735 seriale, o i dischi IDE) e serve in sostanza per indicare al kernel quale è il
2736 modulo che gestisce quella classe di dispositivi. Per identificare uno
2737 specifico dispositivo di quella classe (ad esempio una singola porta seriale,
2738 o uno dei dischi presenti) si usa invece il \textit{minor number}. L'elenco
2739 aggiornato di questi numeri con le relative corrispondenze ai vari dispositivi
2740 può essere trovato nel file \texttt{Documentation/devices.txt} allegato alla
2741 documentazione dei sorgenti del kernel.
2742
2743 Data la crescita nel numero di dispositivi supportati, ben presto il limite
2744 massimo di 256 si è rivelato troppo basso, e nel passaggio dai kernel della
2745 serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo
2746 \type{dev\_t}, con delle dimensioni passate a 12 bit per il \textit{major
2747   number} e 20 bit per il \textit{minor number}. La transizione però ha
2748 comportato il fatto che \type{dev\_t} è diventato un tipo opaco, e la
2749 necessità di specificare il numero tramite delle opportune macro, così da non
2750 avere problemi di compatibilità con eventuali ulteriori estensioni.
2751
2752 Le macro sono definite nel file \headfiled{sys/sysmacros.h},\footnote{se si
2753   usa la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
2754   versioni specifiche di questa libreria, \macrod{gnu\_dev\_major},
2755   \macrod{gnu\_dev\_minor} e \macrod{gnu\_dev\_makedev} che si possono usare
2756   direttamente, al costo di una minore portabilità.} che viene automaticamente
2757 incluso quando si include \headfile{sys/types.h}. Si possono pertanto ottenere
2758 i valori del \textit{major number} e \textit{minor number} di un dispositivo
2759 rispettivamente con le macro \macro{major} e \macro{minor}:
2760
2761 {\centering
2762 \vspace{3pt}
2763 \begin{funcbox}{
2764 \fhead{sys/types.h}
2765 \fdecl{int \macrod{major}(dev\_t dev)}
2766 \fdesc{Restituisce il \textit{major number} del dispositivo \param{dev}.}
2767 \fdecl{int \macrod{minor}(dev\_t dev)}
2768 \fdesc{Restituisce il \textit{minor number} del dispositivo \param{dev}.}  
2769
2770 \end{funcbox}
2771 }
2772
2773 \noindent mentre una volta che siano noti \textit{major number} e
2774 \textit{minor number} si potrà costruire il relativo identificativo con la
2775 macro \macro{makedev}:
2776
2777 {\centering
2778 \vspace{3pt}
2779 \begin{funcbox}{
2780 \fhead{sys/types.h}
2781 \fdecl{dev\_t \macrod{makedev}(int major, int minor)}
2782 \fdesc{Dati \textit{major number} e \textit{minor number} restituisce
2783   l'identificativo di un dispositivo.} 
2784
2785 \end{funcbox}
2786 }
2787
2788
2789 \itindend{major~number}
2790 \itindend{minor~number}
2791 \index{file!di~dispositivo|)}
2792
2793 Dato che la funzione di sistema \func{mknod} presenta diverse varianti nei
2794 vari sistemi unix-like, lo standard POSIX.1-2001 la dichiara portabile solo in
2795 caso di creazione delle \textit{fifo}, ma anche in questo caso alcune
2796 combinazioni degli argomenti restano non specificate, per cui nello stesso
2797 standard è stata introdotta una funzione specifica per creare una
2798 \textit{fifo} deprecando l'uso di \func{mknod} a tale riguardo.  La funzione è
2799 \funcd{mkfifo} ed il suo prototipo è:
2800
2801 \begin{funcproto}{
2802 \fhead{sys/types.h}
2803 \fhead{sys/stat.h}
2804 \fdecl{int mkfifo(const char *pathname, mode\_t mode)}
2805 \fdesc{Crea una \textit{fifo}.} 
2806 }
2807 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2808   caso \var{errno} assumerà \errval{EACCES}, \errval{EEXIST},
2809   \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOSPC}, \errval{ENOTDIR} e
2810   \errval{EROFS} nel loro significato generico.}
2811 \end{funcproto}
2812
2813 La funzione crea la \textit{fifo} \param{pathname} con i
2814 permessi \param{mode}. Come per \func{mknod} il file \param{pathname} non deve
2815 esistere (neanche come collegamento simbolico); al solito i permessi
2816 specificati da \param{mode} vengono modificati dal valore di \textit{umask}
2817 (vedi sez.~\ref{sec:file_perm_management}).
2818
2819 \index{file!speciali|)} 
2820
2821
2822 \subsection{I file temporanei}
2823 \label{sec:file_temp_file}
2824
2825 In molte occasioni è utile poter creare dei file temporanei; benché la cosa
2826 sembri semplice, in realtà il problema è più sottile di quanto non appaia a
2827 prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
2828 creare il file dopo aver controllato che questo non esista, nel momento fra il
2829 controllo e la creazione si ha giusto lo spazio per una possibile \textit{race
2830   condition} (si ricordi quanto visto in sez.~\ref{sec:proc_race_cond}).
2831
2832 \itindbeg{symlink~attack}
2833
2834 Molti problemi di sicurezza derivano proprio da una creazione non accorta di
2835 file temporanei che lascia aperta questa \textit{race condition}. Un
2836 attaccante allora potrà sfruttarla con quello che viene chiamato
2837 ``\textit{symlink attack}'' dove nell'intervallo fra la generazione di un nome
2838 e l'accesso allo stesso, viene creato un collegamento simbolico con quel nome
2839 verso un file diverso, ottenendo, se il programma sotto attacco ne ha la
2840 capacità, un accesso privilegiato.
2841
2842 \itindend{symlink~attack}
2843
2844 La \acr{glibc} provvede varie funzioni per generare nomi di file temporanei,
2845 di cui si abbia certezza di unicità al momento della generazione; storicamente
2846 la prima di queste funzioni create a questo scopo era
2847 \funcd{tmpnam},\footnote{la funzione è stata deprecata nella revisione
2848   POSIX.1-2008 dello standard POSIX.} il cui prototipo è:
2849
2850 \begin{funcproto}{
2851 \fhead{stdio.h}
2852 \fdecl{char *tmpnam(char *string)}
2853 \fdesc{Genera un nome univoco per un file temporaneo.} 
2854 }
2855 {La funzione ritorna il puntatore alla stringa con il nome in caso di successo
2856   e \val{NULL} in caso di fallimento, non sono definiti errori.}
2857 \end{funcproto}
2858
2859 La funzione restituisce il puntatore ad una stringa contente un nome di file
2860 valido e non esistente al momento dell'invocazione. Se si è passato come
2861 argomento \param{string} un puntatore non nullo ad un buffer di caratteri
2862 questo deve essere di dimensione \constd{L\_tmpnam} ed il nome generato vi
2863 verrà copiato automaticamente, altrimenti il nome sarà generato in un buffer
2864 statico interno che verrà sovrascritto ad una chiamata successiva.  Successive
2865 invocazioni della funzione continueranno a restituire nomi unici fino ad un
2866 massimo di \constd{TMP\_MAX} volte, limite oltre il quale il comportamento è
2867 indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
2868 specificata dalla costante \constd{P\_tmpdir}.\footnote{le costanti
2869   \const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
2870   \headfile{stdio.h}.}
2871
2872 Di questa funzione esiste una versione rientrante, \funcm{tmpnam\_r}, che non
2873 fa nulla quando si passa \val{NULL} come argomento.  Una funzione simile,
2874 \funcd{tempnam}, permette di specificare un prefisso per il file
2875 esplicitamente, il suo prototipo è:
2876
2877 \begin{funcproto}{
2878 \fhead{stdio.h}
2879 \fdecl{char *tempnam(const char *dir, const char *pfx)}
2880 \fdesc{Genera un nome univoco per un file temporaneo.} 
2881 }
2882 {La funzione ritorna il puntatore alla stringa con il nome in caso di successo
2883   e \val{NULL} per un errore, nel qual caso \var{errno} potrà assumere solo il
2884   valore \errval{ENOMEM} qualora fallisca l'allocazione della stringa.}
2885 \end{funcproto}
2886
2887 La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
2888 per cui è sempre rientrante, occorre però ricordarsi di disallocare con
2889 \code{free} il puntatore che restituisce.  L'argomento \param{pfx} specifica
2890 un prefisso di massimo 5 caratteri per il nome provvisorio. La funzione
2891 assegna come directory per il file temporaneo, verificando che esista e sia
2892 accessibile, la prima valida fra le seguenti:
2893 \begin{itemize*}
2894 \item la variabile di ambiente \envvar{TMPDIR} (non ha effetto se non è
2895   definita o se il programma chiamante è \acr{suid} o \acr{sgid}, vedi
2896   sez.~\ref{sec:file_special_perm}),
2897 \item il valore dell'argomento \param{dir} (se diverso da \val{NULL}),
2898 \item il valore della costante \const{P\_tmpdir},
2899 \item la directory \file{/tmp}.
2900 \end{itemize*}
2901
2902 In ogni caso, anche se con queste funzioni la generazione del nome è casuale,
2903 ed è molto difficile ottenere un nome duplicato, nulla assicura che un altro
2904 processo non possa avere creato, fra l'ottenimento del nome e l'apertura del
2905 file, un altro file o un collegamento simbolico con lo stesso nome. Per questo
2906 motivo quando si usa il nome ottenuto da una di queste funzioni occorre sempre
2907 assicurarsi che non si stia usando un collegamento simbolico e aprire il nuovo
2908 file in modalità di esclusione (cioè con l'opzione \const{O\_EXCL} per i file
2909 descriptor o con il flag ``\texttt{x}'' per gli \textit{stream}) che fa
2910 fallire l'apertura in caso il file sia già esistente. Essendo disponibili
2911 alternative migliori l'uso di queste funzioni è deprecato.
2912
2913 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
2914 POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
2915 maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
2916
2917 \begin{funcproto}{
2918 \fhead{stdio.h}
2919 \fdecl{FILE *tmpfile(void)}
2920 \fdesc{Apre un file temporaneo in lettura/scrittura.} 
2921 }
2922 {La funzione ritorna il puntatore allo \textit{stream} associato al file
2923   temporaneo in caso di successo e \val{NULL} per un errore, nel qual caso
2924   \var{errno} assumerà uno dei valori:
2925   \begin{errlist}
2926     \item[\errcode{EEXIST}] non è stato possibile generare un nome univoco.
2927     \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
2928   \end{errlist}
2929   ed inoltre \errval{EFAULT}, \errval{EMFILE}, \errval{ENFILE},
2930   \errval{ENOSPC}, \errval{EROFS} e \errval{EACCES} nel loro significato
2931   generico.}
2932 \end{funcproto}
2933
2934
2935 La funzione restituisce direttamente uno \textit{stream} già aperto (in
2936 modalità \code{w+b}, si veda sez.~\ref{sec:file_fopen}) e pronto per l'uso,
2937 che viene automaticamente cancellato alla sua chiusura o all'uscita dal
2938 programma. Lo standard non specifica in quale directory verrà aperto il file,
2939 ma la \acr{glibc} prima tenta con \const{P\_tmpdir} e poi con
2940 \file{/tmp}. Questa funzione è rientrante e non soffre di problemi di
2941 \textit{race condition}.
2942
2943 Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
2944 caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
2945 modificano una stringa di input che serve da modello e che deve essere
2946 conclusa da 6 caratteri ``\texttt{X}'' che verranno sostituiti da un codice
2947 unico. La prima delle due è analoga a \func{tmpnam} e genera soltanto un nome
2948 casuale, il suo prototipo è:
2949
2950 \begin{funcproto}{
2951 \fhead{stlib.h}
2952 \fdecl{char *mktemp(char *template)}
2953 \fdesc{Genera un nome univoco per un file temporaneo.} 
2954 }
2955 {La funzione ritorna  il puntatore a \param{template} in caso di successo e
2956   \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno dei valori: 
2957   \begin{errlist}
2958     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
2959   \end{errlist}}
2960 \end{funcproto}
2961
2962 La funzione genera un nome univoco sostituendo le \code{XXXXXX} finali di
2963 \param{template}; dato che \param{template} deve poter essere modificata dalla
2964 funzione non si può usare una stringa costante.  Tutte le avvertenze riguardo
2965 alle possibili \textit{race condition} date per \func{tmpnam} continuano a
2966 valere; inoltre in alcune vecchie implementazioni il valore usato per
2967 sostituire le \code{XXXXXX} viene formato con il \ids{PID} del processo più
2968 una lettera, il che mette a disposizione solo 26 possibilità diverse per il
2969 nome del file, e rende il nome temporaneo facile da indovinare.  Per tutti
2970 questi motivi la funzione è deprecata e non dovrebbe mai essere usata.
2971
2972 La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
2973 \func{tmpfile}, ma restituisce un file descriptor invece di un nome; il suo
2974 prototipo è:
2975
2976 \begin{funcproto}{
2977 \fhead{stlib.h}
2978 \fdecl{int mkstemp(char *template)}
2979 \fdesc{Apre un file temporaneo.} 
2980 }
2981
2982 {La funzione ritorna il file descriptor in caso di successo e $-1$ per un
2983   errore, nel qual 
2984   caso \var{errno} assumerà uno dei valori: 
2985   \begin{errlist}
2986     \item[\errcode{EEXIST}] non è riuscita a creare un file temporaneo, il
2987       contenuto di \param{template} è indefinito.
2988     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
2989   \end{errlist}}
2990 \end{funcproto}
2991
2992
2993 Come per \func{mktemp} anche in questo caso \param{template} non può essere
2994 una stringa costante. La funzione apre un file in lettura/scrittura con la
2995 funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda
2996 sez.~\ref{sec:file_open_close}), in questo modo al ritorno della funzione si
2997 ha la certezza di essere stati i creatori del file, i cui permessi (si veda
2998 sez.~\ref{sec:file_perm_overview}) sono impostati al valore \code{0600}
2999 (lettura e scrittura solo per il proprietario).\footnote{questo è vero a
3000   partire dalla \acr{glibc} 2.0.7, le versioni precedenti della \acr{glibc} e
3001   le vecchie \acr{libc5} e \acr{libc4} usavano il valore \code{0666} che
3002   permetteva a chiunque di leggere e scrivere i contenuti del file.}  Di
3003 questa funzione esiste una variante \funcd{mkostemp}, introdotta
3004 specificamente dalla \acr{glibc},\footnote{la funzione è stata introdotta
3005   nella versione 2.7 delle librerie e richiede che sia definita la macro
3006   \macro{\_GNU\_SOURCE}.} il cui prototipo è:
3007
3008 \begin{funcproto}{
3009 \fhead{stlib.h}
3010 \fdecl{int mkostemp(char *template, int flags)}
3011 \fdesc{Apre un file temporaneo.} 
3012 }
3013 {La funzione ritorna un file descriptor in caso di successo e $-1$ per un
3014   errore, nel qual caso \var{errno} assumerà  gli stessi valori di
3015   \func{mkstemp}.} 
3016 \end{funcproto}
3017 \noindent la cui sola differenza è la presenza dell'ulteriore argomento
3018 \var{flags} che consente di specificare i flag da passare ad \func{open}
3019 nell'apertura del file.
3020
3021
3022 In OpenBSD è stata introdotta un'altra funzione simile alle precedenti,
3023 \funcd{mkdtemp}, che crea invece una directory temporanea;\footnote{la
3024   funzione è stata introdotta nella \acr{glibc} a partire dalla versione
3025   2.1.91 ed inserita nello standard POSIX.1-2008.}  il suo prototipo è:
3026
3027 \begin{funcproto}{
3028 \fhead{stlib.h}
3029 \fdecl{char *mkdtemp(char *template)}
3030 \fdesc{Crea una directory temporanea.} 
3031 }
3032 {La funzione ritorna il puntatore al nome della directory in caso di successo
3033   e \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno dei
3034   valori:
3035   \begin{errlist}
3036     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
3037   \end{errlist}
3038   più gli altri eventuali codici di errore di \func{mkdir}.}
3039 \end{funcproto}
3040
3041 La funzione crea una directory temporanea il cui nome è ottenuto sostituendo
3042 le \code{XXXXXX} finali di \param{template} con permessi \code{0700} (si veda
3043 sez.~\ref{sec:file_perm_overview} per i dettagli). Dato che la creazione della
3044 directory è sempre esclusiva i precedenti problemi di \textit{race condition}
3045 non si pongono.
3046
3047
3048
3049
3050
3051 \section{La manipolazione delle caratteristiche dei file}
3052 \label{sec:file_infos}
3053
3054 Come spiegato in sez.~\ref{sec:file_filesystem} tutte le informazioni generali
3055 relative alle caratteristiche di ciascun file, a partire dalle informazioni
3056 relative al controllo di accesso, sono mantenute nell'\textit{inode}. Vedremo
3057 in questa sezione come sia possibile leggere tutte queste informazioni usando
3058 la funzione \func{stat}, che permette l'accesso a tutti i dati memorizzati
3059 nell'\textit{inode}; esamineremo poi le varie funzioni usate per manipolare
3060 tutte queste informazioni, eccetto quelle che riguardano la gestione del
3061 controllo di accesso, trattate in in sez.~\ref{sec:file_access_control}.
3062
3063
3064 \subsection{La lettura delle caratteristiche dei file}
3065 \label{sec:file_stat}
3066
3067 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
3068 delle funzioni \func{stat} che sono quelle che usa il comando \cmd{ls} per
3069 poter ottenere e mostrare tutti i dati relativi ad un file; ne fanno parte le
3070 funzioni di sistema \funcd{stat}, \funcd{fstat} e \funcd{lstat}, i cui
3071 prototipi sono:
3072
3073 \begin{funcproto}{
3074 \fhead{sys/types.h}
3075 \fhead{sys/stat.h}
3076 \fhead{unistd.h}
3077 \fdecl{int stat(const char *file\_name, struct stat *buf)}
3078 \fdecl{int lstat(const char *file\_name, struct stat *buf)}
3079 \fdecl{int fstat(int filedes, struct stat *buf)}
3080 \fdesc{Leggono le informazioni di un file.} 
3081 }
3082 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
3083   caso \var{errno} assumerà uno dei valori:
3084   \begin{errlist}
3085     \item[\errcode{EOVERFLOW}] il file ha una dimensione che non può essere
3086       rappresentata nel tipo \type{off\_t} (può avvenire solo in caso di
3087       programmi compilati su piattaforme a 32 bit senza le estensioni
3088       (\texttt{-D \_FILE\_OFFSET\_BITS=64}) per file a 64 bit).
3089   \end{errlist}
3090   ed inoltre \errval{EFAULT} ed \errval{ENOMEM}, per \func{stat} e
3091   \func{lstat} anche \errval{EACCES}, \errval{ELOOP}, \errval{ENAMETOOLONG},
3092   \errval{ENOENT}, \errval{ENOTDIR}, per \func{fstat} anche \errval{EBADF}, 
3093   nel loro significato generico.}
3094 \end{funcproto}
3095
3096 La funzione \func{stat} legge le informazioni del file indicato
3097 da \param{file\_name} e le inserisce nel buffer puntato
3098 dall'argomento \param{buf}; la funzione \func{lstat} è identica a \func{stat}
3099 eccetto che se \param{file\_name} è un collegamento simbolico vengono lette le
3100 informazioni relative ad esso e non al file a cui fa riferimento. Infine
3101 \func{fstat} esegue la stessa operazione su un file già aperto, specificato
3102 tramite il suo file descriptor \param{filedes}.
3103
3104 La struttura \struct{stat} usata da queste funzioni è definita nell'header
3105 \headfiled{sys/stat.h} e in generale dipende dall'implementazione; la versione
3106 usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
3107 riportata dalla pagina di manuale di \func{stat}. In realtà la definizione
3108 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
3109 riservati per estensioni come tempi dei file più precisi (vedi
3110 sez.~\ref{sec:file_file_times}).
3111
3112 \begin{figure}[!htb]
3113   \footnotesize
3114   \centering
3115   \begin{minipage}[c]{0.8\textwidth}
3116     \includestruct{listati/stat.h}
3117   \end{minipage} 
3118   \normalsize 
3119   \caption{La struttura \structd{stat} per la lettura delle informazioni dei 
3120     file.}
3121   \label{fig:file_stat_struct}
3122 \end{figure}
3123
3124 Si noti come i vari membri della struttura siano specificati come tipi
3125 primitivi del sistema, di quelli definiti in
3126 tab.~\ref{tab:intro_primitive_types}, e dichiarati in \headfile{sys/types.h},
3127 con l'eccezione di \typed{blksize\_t} e \typed{blkcnt\_t} che sono nuovi tipi
3128 introdotti per rendersi indipendenti dalla piattaforma. 
3129
3130 Benché la descrizione dei commenti di fig.~\ref{fig:file_stat_struct} sia
3131 abbastanza chiara, vale la pena illustrare maggiormente il significato dei
3132 campi di \struct{stat} su cui non torneremo in maggior dettaglio nel resto di
3133 questa sezione:
3134 \begin{itemize*}
3135
3136 \item Il campo \var{st\_nlink} contiene il numero di \textit{hard link} che
3137   fanno riferimento al file (il cosiddetto \textit{link count}) di cui abbiamo
3138   già parlato in numerose occasioni.
3139
3140 \item Il campo \var{st\_ino} contiene il numero di \textit{inode} del file,
3141   quello viene usato all'interno del filesystem per identificarlo e che può
3142   essere usato da un programma per determinare se due \textit{pathname} fanno
3143   riferimento allo stesso file.
3144
3145 \item Il campo \var{st\_dev} contiene il numero del dispositivo su cui risiede
3146   il file (o meglio il suo filesystem). Si tratta dello stesso numero che si
3147   usa con \func{mknod} e che può essere decomposto in \textit{major number} e
3148   \textit{minor number} con le macro \macro{major} e \macro{minor} viste in
3149   sez.~\ref{sec:file_mknod}.
3150
3151 \item Il campo \var{st\_rdev} contiene il numero di dispositivo associato al
3152   file stesso ed ovviamente ha un valore significativo soltanto quando il file
3153   è un dispositivo a caratteri o a blocchi.
3154
3155 \item Il campo \var{st\_blksize} contiene la dimensione dei blocchi di dati
3156   usati nell'I/O su disco, che è anche la dimensione usata per la
3157   bufferizzazione dei dati dalle librerie del C per l'interfaccia degli
3158   \textit{stream}.  Leggere o scrivere blocchi di dati in dimensioni inferiori
3159   a questo valore è inefficiente in quanto le operazioni su disco usano
3160   comunque trasferimenti di questa dimensione.
3161
3162 \end{itemize*}
3163
3164 % TODO trattare anche statx, aggiunta con il kernel 4.11 (vedi
3165 % https://lwn.net/Articles/707602/ e
3166 % https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f) 
3167
3168
3169 \subsection{I tipi di file}
3170 \label{sec:file_types}
3171
3172 Abbiamo sottolineato fin dall'introduzione che Linux, come ogni sistema
3173 unix-like, supporta oltre ai file ordinari e alle directory una serie di altri
3174 ``\textsl{tipi}'' di file che possono stare su un filesystem (elencati in
3175 tab.~\ref{tab:file_file_types}).  Il tipo di file viene ritornato dalle
3176 funzioni della famiglia \func{stat} all'interno del campo \var{st\_mode} di
3177 una struttura \struct{stat}. 
3178
3179 Il campo \var{st\_mode} è una maschera binaria in cui l'informazione viene
3180 suddivisa nei vari bit che compongono, ed oltre a quelle sul tipo di file,
3181 contiene anche le informazioni relative ai permessi su cui torneremo in
3182 sez.~\ref{sec:file_perm_overview}. Dato che i valori numerici usati per
3183 definire il tipo di file possono variare a seconda delle implementazioni, lo
3184 standard POSIX definisce un insieme di macro che consentono di verificare il
3185 tipo di file in maniera standardizzata.
3186
3187 \begin{table}[htb]
3188   \centering
3189   \footnotesize
3190   \begin{tabular}[c]{|l|l|}
3191     \hline
3192     \textbf{Macro} & \textbf{Tipo del file} \\
3193     \hline
3194     \hline
3195     \macrod{S\_ISREG}\texttt{(m)}  & File normale.\\
3196     \macrod{S\_ISDIR}\texttt{(m)}  & Directory.\\
3197     \macrod{S\_ISCHR}\texttt{(m)}  & Dispositivo a caratteri.\\
3198     \macrod{S\_ISBLK}\texttt{(m)}  & Dispositivo a blocchi.\\
3199     \macrod{S\_ISFIFO}\texttt{(m)} & \textit{Fifo}.\\
3200     \macrod{S\_ISLNK}\texttt{(m)}  & Collegamento simbolico.\\
3201     \macrod{S\_ISSOCK}\texttt{(m)} & Socket.\\
3202     \hline    
3203   \end{tabular}
3204   \caption{Macro per i tipi di file (definite in \headfile{sys/stat.h}).}
3205   \label{tab:file_type_macro}
3206 \end{table}
3207
3208 Queste macro vengono usate anche da Linux che supporta pure le estensioni allo
3209 standard per i collegamenti simbolici e i socket definite da BSD.\footnote{le
3210   ultime due macro di tab.~\ref{tab:file_type_macro}, che non sono presenti
3211   nello standard POSIX fino alla revisione POSIX.1-1996.}  L'elenco completo
3212 delle macro con cui è possibile estrarre da \var{st\_mode} l'informazione
3213 relativa al tipo di file è riportato in tab.~\ref{tab:file_type_macro}, tutte
3214 le macro restituiscono un valore intero da usare come valore logico e prendono
3215 come argomento il valore di \var{st\_mode}.
3216
3217 \begin{table}[htb]
3218   \centering
3219   \footnotesize
3220   \begin{tabular}[c]{|l|c|l|}
3221     \hline
3222     \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\
3223     \hline
3224     \hline
3225     \constd{S\_IFMT}   &  0170000 & Maschera per i bit del tipo di file.\\
3226     \constd{S\_IFSOCK} &  0140000 & Socket.\\
3227     \constd{S\_IFLNK}  &  0120000 & Collegamento simbolico.\\
3228     \constd{S\_IFREG}  &  0100000 & File regolare.\\ 
3229     \constd{S\_IFBLK}  &  0060000 & Dispositivo a blocchi.\\
3230     \constd{S\_IFDIR}  &  0040000 & Directory.\\
3231     \constd{S\_IFCHR}  &  0020000 & Dispositivo a caratteri.\\
3232     \constd{S\_IFIFO}  &  0010000 & \textit{Fifo}.\\
3233     \hline
3234     \constd{S\_ISUID}  &  0004000 & Set user ID (\acr{suid}) bit, vedi
3235                                    sez.~\ref{sec:file_special_perm}).\\
3236     \constd{S\_ISGID}  &  0002000 & Set group ID (\acr{sgid}) bit, vedi
3237                                    sez.~\ref{sec:file_special_perm}).\\
3238     \constd{S\_ISVTX}  &  0001000 & \acr{Sticky} bit, vedi
3239                                    sez.~\ref{sec:file_special_perm}).\\
3240     \hline
3241     \constd{S\_IRWXU}  &  00700   & Maschera per i permessi del proprietario.\\
3242     \constd{S\_IRUSR}  &  00400   & Il proprietario ha permesso di lettura.\\
3243     \constd{S\_IWUSR}  &  00200   & Il proprietario ha permesso di scrittura.\\
3244     \constd{S\_IXUSR}  &  00100   & Il proprietario ha permesso di esecuzione.\\
3245     \hline
3246     \constd{S\_IRWXG}  &  00070   & Maschera per i permessi del gruppo.\\
3247     \constd{S\_IRGRP}  &  00040   & Il gruppo ha permesso di lettura.\\
3248     \constd{S\_IWGRP}  &  00020   & Il gruppo ha permesso di scrittura.\\
3249     \constd{S\_IXGRP}  &  00010   & Il gruppo ha permesso di esecuzione.\\
3250     \hline
3251     \constd{S\_IRWXO}  &  00007   & Maschera per i permessi di tutti gli altri\\
3252     \constd{S\_IROTH}  &  00004   & Gli altri hanno permesso di lettura.\\
3253     \constd{S\_IWOTH}  &  00002   & Gli altri hanno permesso di esecuzione.\\
3254     \constd{S\_IXOTH}  &  00001   & Gli altri hanno permesso di esecuzione.\\
3255     \hline    
3256   \end{tabular}
3257   \caption{Costanti per l'identificazione dei vari bit che compongono il campo
3258     \var{st\_mode} (definite in \headfile{sys/stat.h}).}
3259   \label{tab:file_mode_flags}
3260 \end{table}
3261
3262 Oltre alle macro di tab.~\ref{tab:file_type_macro}, che semplificano
3263 l'operazione, è possibile usare direttamente il valore di \var{st\_mode} per
3264 ricavare il tipo di file controllando direttamente i vari bit in esso
3265 memorizzati. Per questo sempre in \headfile{sys/stat.h} sono definite le varie
3266 costanti numeriche riportate in tab.~\ref{tab:file_mode_flags}, che
3267 definiscono le maschere che consentono di selezionare non solo i dati relativi
3268 al tipo di file, ma anche le informazioni relative ai permessi su cui
3269 torneremo in sez.~\ref{sec:file_access_control}, ed identificare i rispettivi
3270 valori.
3271
3272 Le costanti che servono per la identificazione del tipo di file sono riportate
3273 nella prima sezione di tab.~\ref{tab:file_mode_flags}, mentre le sezioni
3274 successive attengono alle costanti usate per i permessi.  Il primo valore
3275 dell'elenco è la maschera binaria \const{S\_IFMT} che permette di estrarre da
3276 \var{st\_mode} (con un AND aritmetico) il blocco di bit nei quali viene
3277 memorizzato il tipo di file. I valori successivi sono le costanti
3278 corrispondenti ai vari tipi di file, e possono essere usate per verificare la
3279 presenza del tipo di file voluto ed anche, con opportune combinazioni,
3280 alternative fra più tipi di file. 
3281
3282 Si tenga presente però che a differenza dei permessi, l'informazione relativa
3283 al tipo di file non è una maschera binaria, per questo motivo se si volesse
3284 impostare una condizione che permetta di controllare se un file è una
3285 directory o un file ordinario non si possono controllare dei singoli bit, ma
3286 si dovrebbe usare una macro di preprocessore come:
3287 \includecodesnip{listati/is_regdir.h}
3288 in cui si estraggono ogni volta da \var{st\_mode} i bit relativi al tipo di
3289 file e poi si effettua il confronto con i due possibili tipi di file.
3290
3291
3292 \subsection{Le dimensioni dei file}
3293 \label{sec:file_file_size}
3294
3295 Abbiamo visto in fig.~\ref{fig:file_stat_struct} che campo \var{st\_size} di
3296 una struttura \struct{stat} contiene la dimensione del file in byte. Questo
3297 però è vero solo se si tratta di un file regolare, mentre nel caso di un
3298 collegamento simbolico la dimensione è quella del \textit{pathname} che il
3299 collegamento stesso contiene, infine per le \textit{fifo} ed i file di dispositivo
3300 questo campo è sempre nullo.
3301
3302 Il campo \var{st\_blocks} invece definisce la lunghezza del file in blocchi di
3303 512 byte. La differenza con \var{st\_size} è che in questo caso si fa
3304 riferimento alla quantità di spazio disco allocata per il file, e non alla
3305 dimensione dello stesso che si otterrebbe leggendolo sequenzialmente.
3306
3307 Si deve tener presente infatti che la lunghezza del file riportata in
3308 \var{st\_size} non è detto che corrisponda all'occupazione dello spazio su
3309 disco, e non solo perché la parte finale del file potrebbe riempire
3310 parzialmente un blocco. In un sistema unix-like infatti è possibile
3311 l'esistenza dei cosiddetti \textit{sparse file}, cioè file in cui sono
3312 presenti dei ``\textsl{buchi}'' (\textit{holes} nella nomenclatura inglese)
3313 che si formano tutte le volte che si va a scrivere su un file dopo aver
3314 eseguito uno spostamento oltre la sua fine (tratteremo in dettaglio
3315 l'argomento in sez.~\ref{sec:file_lseek}).
3316
3317 In questo caso si avranno risultati differenti a seconda del modo in cui si
3318 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
3319 numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
3320 legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
3321 caso per i ``\textsl{buchi}'' vengono restituiti degli zeri, si avrà lo stesso
3322 risultato di \cmd{ls}.
3323
3324 Se è sempre possibile allargare un file, scrivendoci sopra o usando la
3325 funzione \func{lseek} (vedi sez.~\ref{sec:file_lseek}) per spostarsi oltre la
3326 sua fine, esistono anche casi in cui si può avere bisogno di effettuare un
3327 troncamento, scartando i dati presenti al di là della dimensione scelta come
3328 nuova fine del file.
3329
3330 Un file può sempre essere troncato a zero aprendolo con il flag
3331 \const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
3332 dimensione si possono usare le due funzioni di sistema \funcd{truncate} e
3333 \funcd{ftruncate}, i cui prototipi sono:
3334
3335 \begin{funcproto}{
3336 \fhead{unistd.h}
3337 \fdecl{int ftruncate(int fd, off\_t length))}
3338 \fdecl{int truncate(const char *file\_name, off\_t length)}
3339 \fdesc{Troncano un file.} 
3340 }
3341 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
3342   caso \var{errno} assumerà uno dei valori: 
3343   \begin{errlist}
3344   \item[\errcode{EINTR}] si è stati interrotti da un segnale.
3345   \item[\errcode{EINVAL}] \param{length} è negativa o maggiore delle
3346     dimensioni massime di un file.
3347   \item[\errcode{EPERM}] il filesystem non supporta il troncamento di un file.
3348   \item[\errcode{ETXTBSY}] il file è un programma in esecuzione.
3349   \end{errlist} 
3350   per entrambe, mentre per \func{ftruncate} si avranno anche: 
3351   \begin{errlist}
3352   \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
3353   \item[\errcode{EINVAL}] \param{fd} non è un riferimento a un file o non è
3354     aperto in scrittura. 
3355   \end{errlist}
3356   e per \func{truncate} si avranno anche: 
3357   \begin{errlist}
3358   \item[\errcode{EACCES}] non si ha il permesso di scrittura sul file o il
3359     permesso di attraversamento di una delle componenti del \textit{pathname}.
3360   \item[\errcode{EISDIR}] \param{file\_name} fa riferimento ad una directory.
3361   \end{errlist}
3362   ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
3363   \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} e \errval{EROFS}
3364   nel loro significato generico.}
3365 \end{funcproto}
3366
3367 Entrambe le funzioni fan sì che la dimensione del file sia troncata ad un
3368 valore massimo specificato da \param{length}, e si distinguono solo per il
3369 fatto che il file viene indicato con un \textit{pathname} per \func{truncate}
3370 e con un file descriptor per \funcd{ftruncate}. Si tenga presente che se il
3371 file è più lungo della lunghezza specificata i dati in eccesso saranno
3372 perduti.
3373
3374 Il comportamento in caso di lunghezza del file inferiore a \param{length} non
3375 è specificato e dipende dall'implementazione: il file può essere lasciato
3376 invariato o esteso fino alla lunghezza scelta. Nel caso di Linux viene esteso
3377 con la creazione di un \textsl{buco} nel file e ad una lettura si otterranno
3378 degli zeri, si tenga presente però che questo comportamento è supportato solo
3379 per filesystem nativi, ad esempio su un filesystem non nativo come il VFAT di
3380 Windows questo non è possibile.
3381
3382
3383 \subsection{I tempi dei file}
3384 \label{sec:file_file_times}
3385
3386 Il sistema mantiene per ciascun file tre tempi, che sono registrati
3387 nell'\textit{inode} insieme agli altri attributi del file. Questi possono
3388 essere letti tramite la funzione \func{stat}, che li restituisce attraverso
3389 tre campi della struttura \struct{stat} di fig.~\ref{fig:file_stat_struct}. Il
3390 significato di questi tempi e dei relativi campi della struttura \struct{stat}
3391 è illustrato nello schema di tab.~\ref{tab:file_file_times}, dove è anche
3392 riportato un esempio delle funzioni che effettuano cambiamenti su di essi. Il
3393 valore del tempo è espresso nel cosiddetto \textit{calendar time}, su cui
3394 torneremo in dettaglio in sez.~\ref{sec:sys_time}.
3395
3396 \begin{table}[htb]
3397   \centering
3398   \footnotesize
3399   \begin{tabular}[c]{|c|l|l|c|}
3400     \hline
3401     \textbf{Membro} & \textbf{Significato} & \textbf{Funzione} 
3402     & \textbf{Opzione di \cmd{ls}} \\
3403     \hline
3404     \hline
3405     \var{st\_atime}& ultimo accesso ai dati del file    &
3406                      \func{read}, \func{utime}          & \cmd{-u}\\
3407     \var{st\_mtime}& ultima modifica ai dati del file   &
3408                      \func{write}, \func{utime}         & default\\
3409     \var{st\_ctime}& ultima modifica ai dati dell'\textit{inode} &
3410                      \func{chmod}, \func{utime}         & \cmd{-c}\\
3411     \hline
3412   \end{tabular}
3413   \caption{I tre tempi associati a ciascun file.}
3414   \label{tab:file_file_times}
3415 \end{table}
3416
3417 Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
3418 ultima modifica (il \textit{modification time}) riportato in \var{st\_mtime},
3419 ed il tempo di ultimo cambiamento di stato (il \textit{change status time})
3420 riportato in \var{st\_ctime}. Il primo infatti fa riferimento ad una modifica
3421 del contenuto di un file, mentre il secondo ad una modifica dei metadati
3422 dell'\textit{inode}. Dato che esistono molte operazioni, come la funzione
3423 \func{link} e altre che vedremo in seguito, che modificano solo le
3424 informazioni contenute nell'\textit{inode} senza toccare il contenuto del
3425 file, diventa necessario l'utilizzo di questo secondo tempo.
3426
3427 Il tempo di ultima modifica viene usato ad esempio da programmi come
3428 \cmd{make} per decidere quali file necessitano di essere ricompilati perché
3429 più recenti dei loro sorgenti oppure dai programmi di backup, talvolta insieme
3430 anche al tempo di cambiamento di stato, per decidere quali file devono essere
3431 aggiornati nell'archiviazione.  Il tempo di ultimo accesso viene di solito
3432 usato per identificare i file che non vengono più utilizzati per un certo
3433 lasso di tempo. Ad esempio un programma come \texttt{leafnode} lo usa per
3434 cancellare gli articoli letti più vecchi, mentre \texttt{mutt} lo usa per
3435 marcare i messaggi di posta che risultano letti.  
3436
3437 Il sistema non tiene mai conto dell'ultimo accesso all'\textit{inode},
3438 pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza
3439 sui tre tempi. Il comando \cmd{ls} (quando usato con le opzioni \cmd{-l} o
3440 \cmd{-t}) mostra i tempi dei file secondo lo schema riportato nell'ultima
3441 colonna di tab.~\ref{tab:file_file_times}. Si noti anche come non esista, a
3442 differenza di altri sistemi operativi, un \textsl{tempo di creazione} di un
3443 file.
3444
3445 L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
3446 difetto progettuale di Unix, questo infatti comporta la necessità di
3447 effettuare un accesso in scrittura sul disco anche in tutti i casi in cui
3448 questa informazione non interessa e sarebbe possibile avere un semplice
3449 accesso in lettura sui dati bufferizzati. Questo comporta un ovvio costo sia
3450 in termini di prestazioni, che di consumo di risorse come la batteria per i
3451 portatili, o i cicli di riscrittura per i dischi su memorie riscrivibili.
3452
3453
3454 Per questo motivo abbiamo visto in sez.~\ref{sec:filesystem_mounting} come
3455 nello sviluppo del kernel siano stati introdotti degli opportuni \textit{mount
3456   flag} che consentissero di evitare di aggiornare continuamente una
3457 informazione che nella maggior parte dei casi non interessa. Per questo i
3458 valori che si possono trovare per l'\textit{access time} dipendono dalle
3459 opzioni di montaggio, ed anche, essendo stato cambiato il comportamento di
3460 default a partire dalla versione 2.6.30, dal kernel che si sta usando. 
3461
3462 In generale quello che si ha con i kernel più recenti è che il tempo di ultimo
3463 accesso viene aggiornato solo se è precedente al tempo di ultima modifica o
3464 cambiamento, o se è passato più di un giorno dall'ultimo accesso. Così si può
3465 rendere evidente che vi è stato un accesso dopo una modifica e che il file
3466 viene comunque osservato regolarmente, conservando tutte le informazioni
3467 veramente utili senza dover consumare risorse in scritture continue per
3468 mantenere costantemente aggiornata una informazione che a questo punto non ha
3469 più nessuna rilevanza pratica.\footnote{qualora ce ne fosse la necessità è
3470   comunque possibile, tramite l'opzione di montaggio \texttt{strictatime},
3471   richiedere in ogni caso il comportamento tradizionale.}
3472
3473 \begin{table}[htb]
3474   \centering
3475   \footnotesize
3476   \begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
3477     \hline
3478     \multicolumn{1}{|p{2.8cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} &
3479     \multicolumn{3}{|p{3.2cm}|}{\centering{
3480         \textbf{File o directory del riferimento}}}&
3481     \multicolumn{3}{|p{3.2cm}|}{\centering{
3482         \textbf{Directory contenente il riferimento}}} 
3483     &\multicolumn{1}{|p{3.4cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\
3484     \cline{2-7}
3485     \cline{2-7}
3486     \multicolumn{1}{|p{2.8cm}|}{} 
3487     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
3488     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
3489     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
3490     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
3491     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
3492     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
3493     &\multicolumn{1}{|p{3cm}|}{} \\
3494     \hline
3495     \hline
3496     \func{chmod}, \func{fchmod} 
3497              & --      & --      &$\bullet$& --      & --      & --      &\\
3498     \func{chown}, \func{fchown} 
3499              & --      & --      &$\bullet$& --      & --      & --      &\\
3500     \func{creat}  
3501              &$\bullet$&$\bullet$&$\bullet$& --      &$\bullet$&$\bullet$&  
3502              con \const{O\_CREATE} \\
3503     \func{creat}  
3504              & --      &$\bullet$&$\bullet$& --      &$\bullet$&$\bullet$&   
3505              con \const{O\_TRUNC} \\
3506     \func{exec}  
3507              &$\bullet$& --      & --      & --      & --      & --      &\\
3508     \func{lchown}  
3509              & --      & --      &$\bullet$& --      & --      & --      &\\
3510     \func{link}
3511              & --      & --      &$\bullet$& --      &$\bullet$&$\bullet$&\\
3512     \func{mkdir}
3513              &$\bullet$&$\bullet$&$\bullet$& --      &$\bullet$&$\bullet$&\\
3514     \func{mknod}
3515              &$\bullet$&$\bullet$&$\bullet$& --      &$\bullet$&$\bullet$&\\
3516     \func{mkfifo}
3517              &$\bullet$&$\bullet$&$\bullet$& --      &$\bullet$&$\bullet$&\\
3518     \func{open}
3519              &$\bullet$&$\bullet$&$\bullet$& --      &$\bullet$&$\bullet$& 
3520              con \const{O\_CREATE} \\
3521     \func{open}
3522              & --      &$\bullet$&$\bullet$& --      & --      & --      & 
3523              con \const{O\_TRUNC}  \\
3524     \func{pipe}
3525              &$\bullet$&$\bullet$&$\bullet$& --      & --      & --      &\\
3526     \func{read}
3527              &$\bullet$& --      & --      & --      & --      & --      &\\
3528     \func{remove}
3529              & --      & --      &$\bullet$& --      &$\bullet$&$\bullet$& 
3530              se esegue \func{unlink}\\
3531     \func{remove}
3532               & --      & --      & --      & --      &$\bullet$&$\bullet$& 
3533               se esegue \func{rmdir}\\
3534     \func{rename}
3535               & --      & --      &$\bullet$& --      &$\bullet$&$\bullet$& 
3536               per entrambi gli argomenti\\
3537     \func{rmdir}
3538               & --      & --      & --      & --      &$\bullet$&$\bullet$&\\ 
3539     \func{truncate}, \func{ftruncate}
3540               & --      &$\bullet$&$\bullet$& --      & --      & --      &\\ 
3541     \func{unlink}
3542               & --      & --      &$\bullet$& --      &$\bullet$&$\bullet$&\\ 
3543     \func{utime}
3544               &$\bullet$&$\bullet$&$\bullet$& --      & --      & --      &\\ 
3545     \func{utimes}
3546               &$\bullet$&$\bullet$&$\bullet$& --      & --      & --      &\\ 
3547     \func{write}
3548               & --      &$\bullet$&$\bullet$& --      & --      & --      &\\ 
3549     \hline
3550   \end{tabular}
3551   \caption{Prospetto dei cambiamenti effettuati sui tempi di ultimo 
3552     accesso \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento di
3553     stato \textsl{(c)} dalle varie funzioni operanti su file e directory.}
3554   \label{tab:file_times_effects}  
3555 \end{table}
3556
3557
3558 L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è
3559 illustrato in tab.~\ref{tab:file_times_effects}, facendo riferimento al
3560 comportamento classico per quanto riguarda \var{st\_atime}. Si sono riportati
3561 gli effetti sia per il file a cui si fa riferimento, sia per la directory che
3562 lo contiene. Questi ultimi possono essere capiti immediatamente se si tiene
3563 conto di quanto già detto e ripetuto a partire da
3564 sez.~\ref{sec:file_filesystem}, e cioè che anche le directory sono anch'esse
3565 file che contengono una lista di nomi, che il sistema tratta in maniera del
3566 tutto analoga a tutti gli altri.
3567
3568 Per questo motivo tutte le volte che compiremo un'operazione su un file che
3569 comporta una modifica del nome contenuto nella directory, andremo anche a
3570 scrivere sulla directory che lo contiene cambiandone il tempo di ultima
3571 modifica. Un esempio di questo tipo di operazione può essere la cancellazione
3572 di un file, invece leggere o scrivere o cambiare i permessi di un file ha
3573 effetti solo sui tempi di quest'ultimo.
3574
3575 Si ricordi infine come \var{st\_ctime} non è il tempo di creazione del file,
3576 che in Unix non esiste, anche se può corrispondervi per file che non sono mai
3577 stati modificati. Per questo motivo, a differenza di quanto avviene con altri
3578 sistemi operativi, quando si copia un file, a meno di preservare