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