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