Sistemati alcuni paragrafi, aggiunta unlink
[gapil.git] / filedir.tex
1 \chapter{Files e directories}
2 \label{cha:files_and_dirs}
3
4 In questo capitolo tratteremo in dettaglio le varie caratteristiche di files e
5 directories, ed in particolare approfondiremo i dettagli su come è organizzata
6 la struttura dei files in un sistema unix; esamineremo poi come è strutturato
7 il sistema base di protezioni e controllo di accesso ai files, e tutta
8 l'interfaccia che permette la manipolazione dei vari attributi di files e
9 directories. Tutto quello che riguarda invece la manipolazione dei contenuti e
10 lasciato ai capitoli successivi.
11
12 Le funzioni che esamineremo in questo capitolo pertanto sono quelle che
13 permettono di creare e cancellare o leggere le directories, rinominare o
14 cancellare i files ed esaminare o cambiare i loro attributi.
15
16
17 \section{L'organizzazione di files e directories}
18 \label{sec:filedir_org}
19
20 L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
21 medesimi nell'albero descritto brevemente in \ref{sec:fileintr_overview}; una
22 directory comunque, come già specificato in \ref{sec:fileintr_vfs}, è solo un
23 particolare tipo di file che contiene le informazioni che associano un nome al
24 contenuto. Per questo, anche se è usuale parlare di ``file in una directory''
25 in realtà una directory contiene solo dei riferimenti ai file, non i file
26 stessi.
27
28 I nomi contenuti nelle directory sono chiamati componenti (\textit{file name
29   components}), un file può essere indicato rispetto alla directory corrente
30 semplicemente specificando il nome da essa contenuto. Una directory contiene
31 semplicemente un elenco di questi componenti, che possono corrispondere a un
32 qualunque oggetto del filesystem, compresa un'altra directory; l'albero viene
33 appunto creato inserendo directory in altre directory.
34
35 Il nome di file generico è composto da una serie di \textsl{componenti}
36 separati da una \texttt{/} (in linux più \texttt{/} consecutive sono
37 considerate equivalenti ad una sola). Il nome completo di un file viene
38 usualmente chiamato \textit{pathname}, e anche se il manuale della glibc
39 depreca questo nome (poichè genererebbe confusione, dato che con \textit{path}
40 si indica anche un insieme di directory su cui effettuare una ricerca, come
41 quello in cui si cercano i comandi) l'uso è ormai così comune che è senz'altro
42 più chiaro dell'alternativa proposta.
43
44 Il processo con cui si associa ad un pathname uno specifico file (cioè si
45 identifica l'inode a cui fare riferimento) è chiamato risoluzione del nome
46 (\textit{file name resolution} o \textit{pathname resolution}).
47 La risoluzione viene fatta esaminando il pathname da destra a sinistra e
48 localizzando ogni componente nella directory indicata dal componente
49 precedente: ovviamente perché il procedimento funzioni occorre che i
50 componenti indicati come directory esistano e siano effettivamente directory,
51 inoltre i permessi devono consentire l'accesso.
52
53 Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
54 del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
55 seguito, vedi \ref{sec:proc_chroot}) è la stessa per tutti i processi ed
56 equivale alla directory radice dell'albero (come descritto in
57 \ref{sec:fileintr_overview}): in questo caso si parla di un pathname
58 \textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
59 cui torneremo più avanti in \ref{sec:filedir_work_dir}) ed il pathname è detto
60 \textsl{relativo}.
61
62 I componenti \texttt{.} e \texttt{..} hanno un significato speciale e vengono
63 inseriti in ogni directory, il primo fa riferimento alla directory corrente e
64 il secondo alla directory \textsl{genitore} (\textit{parent directory}) cioè
65 la directory che contiene il riferimento alla directory corrente; nel caso
66 questa sia la directory radice allora il riferimento è a se stessa.
67
68
69 \section{La manipolazione di files e directories}
70 \label{sec:filedir_handling}
71
72 Per capire fino in fondo le proprietà di files e directories in un sistema
73 unix ed il funzionamento delle relative funzioni di manipolazione occorre una
74 breve introduzione agli oggetti su cui è basato un filesystem unix; in
75 particolare si riprenderanno, approfondendoli, i concetti di \textit{inode} e
76 \textit{dentry} brevemente introdotti in \ref{sec:fileintr_vfs}.
77
78
79 \subsection{Il funzionamento di un filesystem}
80 \label{sec:filedir_filesystem}
81
82 Come già accennato in \ref{sec:fileintr_overview} linux (ed ogni unix in
83 generale) organizza i dati che tiene su disco attraverso l'uso di un
84 filesystem. Una delle caratteristiche di linux rispetto agli altri unix è
85 quella di poter supportare grazie al VFS una enorme quantità di filesystem
86 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
87 proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
88 daremo una descrizione a grandi linee che si adatta alle caratteristiche
89 comuni di un qualunque filesystem standard unix.
90
91 Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
92 partizione può contenere un filesystem; quest'ultimo è in genere strutturato
93 secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio aa
94 disposizione per i dati e le directory.
95
96 \begin{figure}[htb]
97   \centering
98   
99   \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
100   \label{fig:filedir_disk_filesys}
101 \end{figure}
102
103 Se si va ad esaminare come è strutturata l'informazione all'interno di un
104 singolo filesystem (tralasciando le parti connesse alla strutturazione e al
105 funzionamento del filesystem stesso come il super-block) avremo una situazione
106 del tipo di quella esposta in \nfig.
107 \begin{figure}[htb]
108   \centering
109   
110   \caption{Organizzazione di un filesystem}
111   \label{fig:filedir_filesys_detail}
112 \end{figure}
113 da questa figura si evidenzano alcune caratteristiche su cui è bene porre
114 attenzione in quanto sono fondamentali per capire il funzionamento delle
115 funzioni che manipolano i file e le directory su cui torneremo fra poco; in
116 particolare è opportuno ricordare sempre che:
117
118 \begin{itemize}
119   
120 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
121   tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
122   fisici che contengono i dati e così via; le informazioni che la funzione
123   \texttt{stat} fornisce provengono dall'\textit{inode}; dentro una directory
124   si troverà solo il nome del file e il numero dell'\textit{inode} ad esso
125   associato, cioè quella che da qui in poi chiameremo una \textit{dentry}.
126   
127 \item Come mostrato in \curfig si possono avere più \textit{dentries} che
128   puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un contatore che
129   contiene il numero di riferimenti (\textit{link count}) che sono stati fatti
130   ad esso, solo quando questo contatore si annulla i dati del file vengono
131   effettivamente rimossi dal disco. Per questo la funzione per cancellare un
132   file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del
133   file, ma si limita a eliminare la \textit{dentry} da una directory e
134   decrementare il numero di riferimenti nell'\textit{inode}.
135   
136 \item Il numero di \textit{inode} nella \textit{dentry} si riferisce ad un
137   \textit{inode} nello stesso filesystem e non ci può essere una directory che
138   contiene riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo
139   limita l'uso del comando \texttt{ln} (che crea una nuova dentry per un file
140   esistente, con la funzione \texttt{link}) al filesystem corrente.
141   
142 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
143   del file non deve essere spostato, viene semplicemente creta una nuova
144   \textit{dentry} per l'\textit{inode} in questione e rimossa la vecchia
145   (questa è la modalità in cui opera normalmente il comando \texttt{mv}
146   attraverso la funzione \texttt{rename}).
147
148 \end{itemize}
149
150 Infine è bene avere presente che essendo file pure loro, esiste un numero di
151 riferimenti anche per le directories; per cui se ad esempio a partire dalla
152 situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir}
153 nella directory corrente avremo una situazione come quella in \nfig, dove per
154 chiarezza abbiamo aggiunto dei numeri di inode.
155
156 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
157 è referenziata dalla directory da cui si era partiti (in cui è inserita la
158 nuova dentry che fa riferiemto a \texttt{textdir}) e dalla dentry \texttt{.}
159 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
160 che non contenga a sua volta altre directories. Al contempo la directory da
161 cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
162 adesso sarà referenziata anche dalla dentry \texttt{..} di \texttt{textdir}.
163
164
165 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
166 \label{sec:filedir_link}
167
168 Una delle caratteristiche usate quando si opera con i file è quella di poter
169 creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
170 stesso file accedendovi da directory diverse. Questo è possibile anche in
171 ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
172 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
173 per fare questa operazione.
174
175 Come si è appena detto l'accesso al contenuto di un file su disco avviene
176 attraverso il suo inode, e il nome che si trova in una directory è solo una
177 etichetta associata ad un puntatore a detto inode.  Questo significa che la
178 realizzazione di un link è immediata in quanto uno stesso file può avere tanti
179 nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo
180 stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una
181 particolare preferenza rispetto agli altri.
182
183 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
184 suole chiamare questo tipo di associazione un collegamento diretto (o
185 \textit{hard link}).  Il prototipo della funzione, definita in
186 \texttt{unistd.h} è il seguente:
187 \begin{itemize}
188 \item \texttt{int link(const char * oldname, const char * newname)}
189   
190   Crea un nuovo collegamento diretto al file indicato da \texttt{oldname}
191   dandogli nome \texttt{newname}.
192   
193   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
194   di errore. La variabile \texttt{errno} viene settata secondo i seguenti
195   codici di errore:
196
197   \begin{itemize}
198   \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
199     stesso filesystem.
200   \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
201     \texttt{newname} non supporta i link diretti.
202   \item \texttt{EACCESS} 
203     Non c'è il permesso di scrittura per la directory in cui si vuole creare
204     il nuovo link.
205   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
206     già.
207   \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
208     numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
209     \ref{sec:xxx_limits}.
210   \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
211     non può essere ampliata.
212   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
213     su un filesystem montato readonly.
214   \end{itemize}
215 \end{itemize}
216
217 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
218 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
219 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
220 richiamato in diverse directory.
221  
222 Per quanto dicevamo in \ref{sec:filedir_filesystem} la creazione del
223 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
224 filesytem; inoltre il filesystem deve supportare i collegamenti diretti (non è
225 il caso ad esempio del filesystem \texttt{vfat} di windows).
226
227 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
228 ma solo l'amministratore è in grado di creare un collegamento diretto ad
229 un'altra directory, questo lo si fa perché in questo caso è possibile creare
230 dei cerchi nel filesystem (vedi \ref{sec:filedir_symlink}) che molti programmi
231 non sono in grado di gestire e la cui rimozione diventa estremamente
232 complicata (in genere occorre far girare il programma \texttt{fsck} per
233 riparare il filesystem).
234
235
236 La rimozione di un file (o più precisamente di una sua dentry) si effettua con
237 la funzione \texttt{unlink}; il suo prototipo, definito in \texttt{unistd.h} è
238 il seguente:
239
240 \begin{itemize}
241 \item \texttt{int unlink(const char * filename)}
242   
243   Cancella il nome specificato dal pathname nella relativa directory e
244   decrementa il numero di riferimenti nel relativo inode.
245   
246   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
247   di errore. La variabile \texttt{errno} viene settata secondo i seguenti
248   codici di errore:
249
250   \begin{itemize}
251   \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
252     stesso filesystem.
253   \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
254     \texttt{newname} non supporta i link diretti.
255   \item \texttt{EACCESS} 
256     Non c'è il permesso di scrittura per la directory in cui si vuole creare
257     il nuovo link.
258   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
259     già.
260   \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
261     numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
262     \ref{sec:xxx_limits}.
263   \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
264     non può essere ampliata.
265   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
266     su un filesystem montato readonly.
267   \end{itemize}
268 \end{itemize}
269
270 Per cancellare 
271
272
273
274
275
276 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
277 della nnome dalla directory e l'incremento/decremento del numero di
278 riferimenti nell'inode deve essere una operazione atomica (cioè non
279 interrompibile da altri) processi, per questo entrambe queste funzioni sono
280 realizzate tramite una singola system call.
281
282
283
284
285 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
286 \label{sec:filedir_cre_canc}
287
288
289 \subsection{I link simbolici}
290 \label{sec:filedir_sym_link}
291
292 Siccome tutto ciò funziona facendo riferimento ad un inode, questa funzione
293 può essere applicata soltanto per file che risiedono sullo stesso filesystem,
294 (dato che solo in questo caso è garantita l'unicità dell'inode) e solo per
295 filesystem di tipo unix. Inoltre in linux non è consentito eseguire un link
296 diretto ad una directory.
297
298 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
299 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
300 come avviene in altri sistemi operativi, dei file che contengono il
301 semplicemente il riferimento ad un altro file (o directory). In questo modo è
302 possibile effettuare link anche attraverso filesystem diversi e a directory, e
303 pure a file che non esistono ancora.
304
305 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
306 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
307 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
308 lettura del contenuto del medesimo e l'applicazione della funzione al file
309 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
310 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
311 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
312 alle informazioni del link invece che a quelle del file a cui esso fa
313 riferimento.
314
315 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
316 dichiarate nell'header file \texttt{unistd.h}.
317
318 \begin{itemize}
319 \item \texttt{int symlink(const char * oldname, const char * newname)}
320   
321   Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
322   nome \texttt{newname}.
323   
324   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
325   di errore. La variabile \texttt{errno} viene settata secondo i codici di
326   errore standard di accesso ai files (trattati in dettaglio in
327   \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
328
329   \begin{itemize}
330   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
331     già.
332   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
333     su un filesystem montato readonly.
334   \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
335     link è piena e non c'è ulteriore spazio disponibile.
336   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
337     \texttt{oldname} o di \texttt{newname}.
338   \end{itemize}
339 \end{itemize}
340
341
342 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} 
343 \label{sec:filedir_dir_creat_rem}
344
345 Per creare una nuova directory si può usare la seguente funzione, omonima
346 dell'analogo comando di shell \texttt{mkdir}; per accedere alla funzioni il
347 programma deve includere il file \texttt{sys/stat.h}.
348
349 \begin{itemize}
350 \item \texttt{char * mkdir (const char * dirname, mode\_t mode)}
351   
352   Questa funzione crea una nuova directory vuota con il nome indicato da
353   \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
354   può essere indicato con il pathname assoluto o relativo.
355   
356   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
357   di errore \texttt{errno} viene settata secondo i codici di errore standard
358   di accesso ai files (trattati in dettaglio in
359   \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
360   \begin{itemize}
361   \item \texttt{EACCESS} 
362     Non c'è il permesso di scrittura per la directory in cui si vuole inserire
363     la nuova directory.
364   \item \texttt{EEXIST} Un file (o una directory) con quel nome essite di già. 
365   \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
366     contiene troppi file. Sotto linux questo normalmente non avviene perchè il
367     filesystem standard consente la creazione di un numero di file maggiore di
368     quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
369     fare anche con filesystem di altri sistemi questo errore può presentarsi.
370   \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
371     la nuova directory.
372   \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
373     directory è su un filesystem montato readonly.
374   \end{itemize}
375 \end{itemize}
376  
377
378 \subsection{Accesso alle directory}
379 \label{sec:filedir_dir_read}
380
381 Benchè le directory siano oggetti del filesystem come tutti gli altri non ha
382 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
383 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
384 contengono o ricerche sui medesimi.
385
386 Per accedere al contenuto delle directory si usano i cosiddetti
387 \textit{directory streams} (chiamati così per l'analogia con i file stream);
388 la funzione \texttt{opendir} apre uno di questi stream e la funzione
389 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
390 \textit{directory entries} (da distinguersi da quelle della cache di cui
391 parlavamo in \ref{sec:fileintr_vfs}) in una opportuna struttura
392 \texttt{struct dirent}.
393
394
395 \subsection{La directory di lavoro}
396 \label{sec:filedir_work_dir}
397
398 A ciascun processo è associato ad una directory nel filesystem che è chiamata
399 directory corrente o directory di lavoro (\textit{current working directory})
400 che è quella a cui si fa riferimento quando un filename è espresso in forma
401 relativa (relativa appunto a questa directory).
402
403 Quando un utente effettua il login questa directory viene settata alla
404 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
405 della shell consente di cambiarla a piacere, spostandosi da una directory ad
406 un'altra.  Siccome la directory corrente resta la stessa quando viene creato
407 un processo figlio, la directory corrente della shell diventa anche la
408 directory corrente di qualunque comando da essa lanciato.
409
410 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
411 corrente. I prototipi di queste funzioni sono dichiarati in \texttt{unistd.h}. 
412
413 \begin{itemize}
414 \item \texttt{char * getcwd (char * buffer, size\_t size)}
415   
416   Restituisce il filename completo della directory di lavoro corrente nella
417   stringa puntata da \texttt{buffer}, che deve essere precedentemente
418   allocata, per una dimensione massima di \texttt{size}. Si può anche
419   specificare un puntatore nullo come \textit{buffer}, nel qual caso la
420   stringa sarà allocata automaticamente per una dimensione pari a
421   \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
422   del pathname altrimenti. In questo caso si deve ricordare di disallocara la
423   stringa una volta cessato il suo utilizzo.
424   
425   La funzione restituisce il puntatore \texttt{buffer} se riesce,
426   \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
427   \texttt{errno} è settata con i seguenti codici di errore:
428
429   \begin{itemize}
430   \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
431     è nullo.
432   \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
433     lunghezza del pathname. 
434   \item \texttt{EACCES} Manca il permesso di lettura o di ricerca su uno dei
435     componenti del pathname (cioè su una delle directory superiori alla
436     corrente).
437   \end{itemize}
438 \end{itemize}
439
440 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
441 fatta per compatibilità all'indietro con BSD, che non consente di specificare
442 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
443 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byters, vedi
444 \ref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
445 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
446 contenere il nome del file, e questa è la ragione principale per cui questa
447 funzione è deprecata.
448
449 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
450 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
451 differenza che essa ritorna il valore della variabile di ambiente
452 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
453 riferimenti simbolici.
454
455 Come già detto in unix anche le directory sono file, è possibile pertanto
456 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
457 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
458 per cambiare directory di lavoro.
459
460 \begin{itemize}
461 \item \texttt{int chdir (const char * pathname)}
462   
463   Come dice il nome (che significa \textit{change directory}) questa funzione
464   serve a cambiare la directory di lavoro a quella speficata dal pathname
465   contenuto nella stringa \texttt{pathname}.
466   
467 \item \texttt{int fchdir (int filedes)} analoga alla precedente, ma usa un
468   file descriptor invece del pathname.
469
470   
471   Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
472   errore, in caso di errore \texttt{errno} viene settata secondo i codici di
473   errore standard di accesso ai files (trattati in dettaglio in
474   \ref{sec:filedir_access_control}) ai quali si aggiunge il codice
475   \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
476   una directory.
477 \end{itemize}
478
479
480
481
482
483
484
485
486 \section{La manipolazione delle caratteristiche dei files}
487 \label{sec:filedir_infos}
488
489
490
491
492 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
493 \label{sec:filedir_stat}
494
495 \subsection{I tipi di file}
496 \label{sec:filedir_file_types}
497
498 \subsection{La dimensione dei file}
499 \label{sec:filedir_file_size}
500
501 \subsection{I tempi dei file}
502 \label{sec:filedir_file_times}
503
504 \subsection{La funzione \texttt{utime}}
505 \label{sec:filedir_utime}
506
507
508
509 \section{Il controllo di accesso ai file}
510 \label{sec:filedir_access_control}
511
512
513 \subsection{I flag \texttt{suid} e \texttt{sgid}}
514 \label{sec:filedir_suid_sgid}
515
516 \subsection{La titolarità di nuovi files e directory}
517 \label{sec:filedir_ownership}
518
519 \subsection{La funzione \texttt{access}}
520 \label{sec:filedir_access}
521
522 \subsection{La funzione \texttt{umask}}
523 \label{sec:filedir_umask}
524
525 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
526 \label{sec:filedir_chmod}
527
528 \subsection{Il flag \texttt{stiky}}
529 \label{sec:filedir_stiky}
530
531 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
532 \label{sec:filedir_chown}
533
534
535
536 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
537 %cosiddetto \textit{inode}; questo conterrà informazioni come il
538 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
539 %completo vedi \ntab), i permessi (vedi \ref{sec:file_perms}), le date (vedi
540 %\ref{sec:file_times}).
541