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 è
  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 dei files}
  71 \label{sec:filedir_file_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 La rimozione di un file (o più precisamente della voce che lo referenzia) si
 240 effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
 241
 242 \begin{prototype}{unistd.h}{int unlink(const char * filename)}
 243   Cancella il nome specificato dal pathname nella relativa directory e
 244   decrementa il numero di riferimenti nel relativo inode. Nel caso di link
 245   simbolico cancella il link simbolico; nel caso di socket, fifo o file di
 246   dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
 247   uno di questi oggetti possono continuare ad utilizzarlo.
 248
 249   La funzione restituisce zero in caso di successo e -1 per un errore, nel
 250   qual caso il file non viene toccato. La variabile \texttt{errno} viene
 251   settata secondo i seguenti codici di errore:
 252   \begin{errlist}
 253   \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
 254     cui si vuole creare il nuovo link o una delle directory del pathname non
 255     consente la ricerca (permesso di esecuzione).
 256   \item \texttt{EPERM} il pathname indica una directory o il filesystem che
 257     contiene \texttt{filename} non consente l'operazione.
 258   \item \texttt{EROFS} \texttt{filename} è su un filesystem montato in sola
 259     lettura.
 260   \item \texttt{EFAULT} la stringa \texttt{filename} è fuori dello spazio di
 261     indirizzi del processo.
 262   \item \texttt{ENAMETOOLONG} il pathname è troppo lungo.
 263   \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
 264     simbolico spezzato.
 265   \item \texttt{ENOTDIR} Uno dei componenti del pathname non è una directory.
 266   \item \texttt{EISDIR} il pathname indica una directory.
 267   \item \texttt{ENOMEM} Memoria insufficiente nel kernel.
 268   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
 269     pathname.
 270   \item \texttt{EIO} Errore di input/output.
 271   \end{errlist}
 272 \end{prototype}
 273
 274 Per cancellare una voce in una directory è necessario avere il permesso di
 275 scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
 276 il diritto di esecuzione sulla directory che la contiene (torneremo in
 277 dettaglio sui permessi e gli attributi fra poco), se inoltre lo
 278 \textit{sticky} bit è settato occorrerà anche essere proprietari del file o
 279 proprietari della directory (o root, per cui nessuna delle restrizioni è
 280 applicata).
 281
 282 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
 283 della nome dalla directory e l'incremento/decremento del numero di
 284 riferimenti nell'inode deve essere una operazione atomica (cioè non
 285 interrompibile da altri) processi, per questo entrambe queste funzioni sono
 286 realizzate tramite una singola system call.
 287
 288 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
 289 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
 290   count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
 291 questo però si aggiunge una altra condizione, e cioè che non ci siano processi
 292 che abbiano detto file aperto. Come accennato questa proprietà viene spesso
 293 usata per essere sicuri di non lasciare file temporanei su disco in caso di
 294 crash dei programmi; la tecnica è quella di aprire il file e chiamare
 295 \texttt{unlink} subito dopo.
 296
 297 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
 298 \label{sec:filedir_cre_canc}
 299
 300 Al contrario di quanto avviene con altri unix in linux non è possibile usare
 301 \texttt{unlink} sulle directory, per cancellare una directory si può usare la
 302 funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
 303 funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
 304 per cancellare un file (e funziona anche per i sistemi che non supportano i
 305 link diretti), che per i file è identica alla \texttt{unlink} e per le
 306 directory è identica alla \texttt{rmdir}:
 307
 308 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
 309   Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e
 310   \texttt{rmdir} per le directory.
 311
 312   La funzione restituisce zero in caso di successo e -1 per un errore, nel
 313   qual caso il file non viene toccato. La variabile \texttt{errno} viene
 314   settata secondo i seguenti codici di errore:
 315   \begin{errlist} {NDT da rivedere}
 316   \item \texttt{EFAULT} la stringa \texttt{filename} è fuori dello spazio di
 317     indirizzi del processo.
 318   \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
 319     cui si vuole creare il nuovo link o una delle directory del pathname non
 320     consente la ricerca (permesso di esecuzione).
 321   \item \texttt{EPERM} il pathname indica una directory o il filesystem che
 322     contiene \texttt{filename} non consente l'operazione.
 323   \item \texttt{EROFS} \texttt{filename} è su un filesystem montato in sola
 324     lettura.
 325   \item \texttt{ENAMETOOLONG} il pathname è troppo lungo.
 326   \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
 327     simbolico spezzato.
 328   \item \texttt{ENOTDIR} Uno dei componenti del pathname non è una directory.
 329   \item \texttt{ENOMEM} Memoria insufficiente nel kernel.
 330   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
 331     pathname.
 332   \end{errlist}
 333 \end{prototype}
 334
 335 Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il
 336 vantaggio nell'uso di questa funzione al posto della chiamata successiva di
 337 \texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente.
 338
 339 \begin{prototype}{stdio.h}
 340 {int rename(const char *oldpath, const char *newpath)}
 341   Rinomina un file, spostandolo fra directory diverse quando richiesto.
 342
 343   La funzione restituisce zero in caso di successo e -1 per un errore, nel
 344   qual caso il file non viene toccato. La variabile \texttt{errno} viene
 345   settata secondo i seguenti codici di errore:
 346   \begin{errlist} {NDT da rivedere}
 347   \item \texttt{EFAULT} la stringa \texttt{filename} è fuori dello spazio di
 348     indirizzi del processo.
 349   \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
 350     cui si vuole creare il nuovo link o una delle directory del pathname non
 351     consente la ricerca (permesso di esecuzione).
 352   \item \texttt{EPERM} il pathname indica una directory o il filesystem che
 353     contiene \texttt{filename} non consente l'operazione.
 354   \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura.
 355   \item \texttt{ENAMETOOLONG} il pathname è troppo lungo.
 356   \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
 357     simbolico spezzato.
 358   \item \texttt{ENOTDIR} Uno dei componenti del pathname non è una directory.
 359   \item \texttt{ENOMEM} Memoria insufficiente nel kernel.
 360   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
 361     pathname.
 362   \item \texttt{EISDIR}
 363   \item \texttt{EXDEV}
 364   \item \texttt{ENOTEMPTY}
 365   \item \texttt{EBUSY}
 366   \item \texttt{EINVAL}
 367   \item \texttt{EMLINK}
 368   \item \texttt{ENOSPC}
 369
 370   \end{errlist}
 371 \end{prototype}
 372
 373 \subsection{I link simbolici}
 374 \label{sec:filedir_sym_link}
 375
 376 Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
 377 funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
 378 in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
 379 tipo unix.  Inoltre in linux non è consentito eseguire un link diretto ad una
 380 directory.
 381
 382 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
 383 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
 384 come avviene in altri sistemi operativi, dei file che contengono il
 385 semplicemente il riferimento ad un altro file (o directory). In questo modo è
 386 possibile effettuare link anche attraverso filesystem diversi e a directory, e
 387 pure a file che non esistono ancora.
 388
 389 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
 390 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
 391 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
 392 lettura del contenuto del medesimo e l'applicazione della funzione al file
 393 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
 394 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
 395 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
 396 alle informazioni del link invece che a quelle del file a cui esso fa
 397 riferimento.
 398
 399 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
 400 dichiarate nell'header file \texttt{unistd.h}.
 401
 402 \begin{prototype}{unistd.h}
 403 {int symlink(const char * oldname, const char * newname)}
 404   Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
 405   nome \texttt{newname}.
 406
 407   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
 408   di errore. La variabile \texttt{errno} viene settata secondo i codici di
 409   errore standard di accesso ai files (trattati in dettaglio in
 410   \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
 411   \begin{errlist} {NDT da rivedere}
 412   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
 413     già.
 414   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
 415     su un filesystem montato readonly.
 416   \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
 417     link è piena e non c'è ulteriore spazio disponibile.
 418   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
 419     \texttt{oldname} o di \texttt{newname}.
 420   \end{errlist}
 421 \end{prototype}
 422
 423 Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare
 424 un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
 425 questa funzione è la:
 426
 427 \begin{prototype}{unistd.h}
 428 {int readlink(const char * path, char * buff, size_t size)}
 429   Legge il contnuto del link simbolico indicato da \texttt{path} nel buffer
 430   \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
 431   carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
 432   piccolo pe contenerla.
 433
 434
 435   La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
 436   -1 per un errore, in caso di errore. La variabile \texttt{errno} viene
 437   settata secondo i codici di errore:
 438   \begin{errlist} {NDT da rivedere}
 439   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
 440     già.
 441   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
 442     su un filesystem montato readonly.
 443   \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
 444     link è piena e non c'è ulteriore spazio disponibile.
 445   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
 446     \texttt{oldname} o di \texttt{newname}.
 447   \end{errlist}
 448 \end{prototype}
 449
 450
 451 \section{Il controllo di accesso ai file}
 452 \label{sec:filedir_access_control}
 453
 454
 455 \subsection{I flag \texttt{suid} e \texttt{sgid}}
 456 \label{sec:filedir_suid_sgid}
 457
 458 \subsection{La titolarità di nuovi files e directory}
 459 \label{sec:filedir_ownership}
 460
 461 \subsection{La funzione \texttt{access}}
 462 \label{sec:filedir_access}
 463
 464 \subsection{La funzione \texttt{umask}}
 465 \label{sec:filedir_umask}
 466
 467 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
 468 \label{sec:filedir_chmod}
 469
 470 \subsection{Il flag \texttt{stiky}}
 471 \label{sec:filedir_stiky}
 472
 473 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
 474 \label{sec:filedir_chown}
 475
 476
 477
 478 \section{La manipolazione delle directories}
 479 \label{sec:filedir_dir_handling}
 480
 481 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
 482 \label{sec:filedir_dir_creat_rem}
 483
 484 Per creare una nuova directory si può usare la seguente funzione, omonima
 485 dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati
 486 programma deve includere il file \texttt{sys/types.h}.
 487
 488 \begin{prototype}{sys/stat.h}
 489 {int mkdir (const char * dirname, mode\_t mode)}
 490   Questa funzione crea una nuova directory vuota con il nome indicato da
 491   \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
 492   può essere indicato con il pathname assoluto o relativo.
 493
 494   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
 495   di errore \texttt{errno} viene settata secondo i codici di errore standard
 496   di accesso ai files (trattati in dettaglio in
 497   \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
 498   \begin{errlist}
 499   \item \texttt{EACCESS}
 500     Non c'è il permesso di scrittura per la directory in cui si vuole inserire
 501     la nuova directory.
 502   \item \texttt{EEXIST} Un file (o una directory) con quel nome essite di già.
 503   \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
 504     contiene troppi file. Sotto linux questo normalmente non avviene perchè il
 505     filesystem standard consente la creazione di un numero di file maggiore di
 506     quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
 507     fare anche con filesystem di altri sistemi questo errore può presentarsi.
 508   \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
 509     la nuova directory.
 510   \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
 511     directory è su un filesystem montato readonly.
 512   \end{errlist}
 513 \end{prototype}
 514
 515
 516 \subsection{Accesso alle directory}
 517 \label{sec:filedir_dir_read}
 518
 519 Benchè le directory siano oggetti del filesystem come tutti gli altri non ha
 520 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
 521 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
 522 contengono o ricerche sui medesimi.
 523
 524 Per accedere al contenuto delle directory si usano i cosiddetti
 525 \textit{directory streams} (chiamati così per l'analogia con i file stream);
 526 la funzione \texttt{opendir} apre uno di questi stream e la funzione
 527 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
 528 \textit{directory entries} (da distinguersi da quelle della cache di cui
 529 parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura
 530 \texttt{struct dirent}.
 531
 532
 533 \subsection{La directory di lavoro}
 534 \label{sec:filedir_work_dir}
 535
 536 A ciascun processo è associato ad una directory nel filesystem che è chiamata
 537 directory corrente o directory di lavoro (\textit{current working directory})
 538 che è quella a cui si fa riferimento quando un filename è espresso in forma
 539 relativa (relativa appunto a questa directory).
 540
 541 Quando un utente effettua il login questa directory viene settata alla
 542 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
 543 della shell consente di cambiarla a piacere, spostandosi da una directory ad
 544 un'altra.  Siccome la directory corrente resta la stessa quando viene creato
 545 un processo figlio, la directory corrente della shell diventa anche la
 546 directory corrente di qualunque comando da essa lanciato.
 547
 548 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
 549 corrente.
 550
 551 \begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
 552   Restituisce il filename completo della directory di lavoro corrente nella
 553   stringa puntata da \texttt{buffer}, che deve essere precedentemente
 554   allocata, per una dimensione massima di \texttt{size}. Si può anche
 555   specificare un puntatore nullo come \textit{buffer}, nel qual caso la
 556   stringa sarà allocata automaticamente per una dimensione pari a
 557   \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
 558   del pathname altrimenti. In questo caso si deve ricordare di disallocara la
 559   stringa una volta cessato il suo utilizzo.
 560
 561   La funzione restituisce il puntatore \texttt{buffer} se riesce,
 562   \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
 563   \texttt{errno} è settata con i seguenti codici di errore:
 564   \begin{errlist}
 565   \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
 566     è nullo.
 567   \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
 568     lunghezza del pathname.
 569   \item \texttt{EACCES} Manca il permesso di lettura o di ricerca su uno dei
 570     componenti del pathname (cioè su una delle directory superiori alla
 571     corrente).
 572   \end{errlist}
 573 \end{prototype}
 574
 575 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
 576 fatta per compatibilità all'indietro con BSD, che non consente di specificare
 577 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
 578 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byters, vedi
 579 \secref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
 580 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
 581 contenere il nome del file, e questa è la ragione principale per cui questa
 582 funzione è deprecata.
 583
 584 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
 585 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
 586 differenza che essa ritorna il valore della variabile di ambiente
 587 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
 588 riferimenti simbolici.
 589
 590 Come già detto in unix anche le directory sono file, è possibile pertanto
 591 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
 592 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
 593 per cambiare directory di lavoro.
 594
 595 \begin{prototype}{unistd.h}{int chdir (const char * pathname)}
 596   Come dice il nome (che significa \textit{change directory}) questa funzione
 597   serve a cambiare la directory di lavoro a quella speficata dal pathname
 598   contenuto nella stringa \texttt{pathname}.
 599 \end{prototype}
 600
 601 \begin{prototype}{unistd.h}{int fchdir (int filedes)}
 602   Analoga alla precedente, ma usa un file descriptor invece del pathname.
 603
 604   Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
 605   errore, in caso di errore \texttt{errno} viene settata secondo i codici di
 606   errore standard di accesso ai files (trattati in dettaglio in
 607   \secref{sec:filedir_access_control}) ai quali si aggiunge il codice
 608   \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
 609   una directory.
 610 \end{prototype}
 611
 612
 613 \section{La manipolazione delle caratteristiche dei files}
 614 \label{sec:filedir_infos}
 615
 616
 617 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
 618 \label{sec:filedir_stat}
 619
 620 \subsection{I tipi di file}
 621 \label{sec:filedir_file_types}
 622
 623 \subsection{La dimensione dei file}
 624 \label{sec:filedir_file_size}
 625
 626 \subsection{I tempi dei file}
 627 \label{sec:filedir_file_times}
 628
 629 \subsection{La funzione \texttt{utime}}
 630 \label{sec:filedir_utime}
 631
 632
 633
 634
 635 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
 636 %cosiddetto \textit{inode}; questo conterrà informazioni come il
 637 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
 638 %completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
 639 %\secref{sec:file_times}).
 640