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 della 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 o è una directory.
 202   \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori
 203     dello spazio di indirizzi del processo.
 204   \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
 205     per attraversare le directories), vedi \secref{sec:filedir_access_control}
 206     per i dettagli.
 207   \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo.
 208   \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath}
 209     non esiste o è un link simbolico spezzato.
 210   \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath}
 211     non è una directory.
 212   \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
 213     completare l'operazione.
 214   \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è
 215     su un filesystem montato readonly.
 216   \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di
 217     già.
 218   \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il
 219     numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
 220     \secref{sec:xxx_limits}).
 221   \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione
 222     di \texttt{oldpath} o \texttt{newpath}.
 223   \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha
 224     spazio per ulteriori voci.
 225   \item \texttt{EIO} c'è stato un errore di input/output.
 226   \end{errlist}
 227 \end{prototype}
 228
 229 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
 230 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
 231 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
 232 richiamato in diverse directory.
 233
 234 Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del
 235 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
 236 filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
 237 il caso ad esempio del filesystem \texttt{vfat} di windows).
 238
 239 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
 240 ma solo l'amministratore è in grado di creare un collegamento diretto ad
 241 un'altra directory, questo lo si fa perché in questo caso è possibile creare
 242 dei circoli nel filesystem (vedi \secref{sec:filedir_symlink}) che molti
 243 programmi non sono in grado di gestire e la cui rimozione diventa estremamente
 244 complicata (in genere occorre far girare il programma \texttt{fsck} per
 245 riparare il filesystem); data la sua pericolosità in Linux questa
 246 caratteristica è stata disabilitata, e la funzione restituisce l'errore
 247 \texttt{EPERM}.
 248
 249 La rimozione di un file (o più precisamente della voce che lo referenzia) si
 250 effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
 251
 252 \begin{prototype}{unistd.h}{int unlink(const char * pathname)}
 253   Cancella il nome specificato dal pathname nella relativa directory e
 254   decrementa il numero di riferimenti nel relativo inode. Nel caso di link
 255   simbolico cancella il link simbolico; nel caso di socket, fifo o file di
 256   dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
 257   uno di questi oggetti possono continuare ad utilizzarlo.
 258
 259   La funzione restituisce zero in caso di successo e -1 per un errore, nel
 260   qual caso il file non viene toccato. La variabile \texttt{errno} viene
 261   settata secondo i seguenti codici di errore:
 262   \begin{errlist}
 263   \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
 264     per attraversare le directories), vedi \secref{sec:filedir_access_control}
 265     per i dettagli.
 266   \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory
 267     (valore specifico ritornato da linux che non consente l'uso di
 268     \texttt{unlink} con le directory, e non conforme allo standard POSIX, che
 269     prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia
 270     consnetita o il processo non abbia privilegi sufficienti).
 271   \item \texttt{EFAULT} la stringa
 272     passata come parametro è fuori dello spazio di indirizzi del processo.
 273   \item \texttt{ENAMETOOLONG} il pathname troppo lungo.
 274   \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link
 275     simbolico spezzato.
 276   \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory.
 277   \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory.
 278   \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
 279     completare l'operazione.
 280   \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola
 281     lettura.
 282   \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del
 283     pathname.
 284   \item \texttt{EIO} errore di input/output.
 285   \end{errlist}
 286 \end{prototype}
 287
 288 Per cancellare una voce in una directory è necessario avere il permesso di
 289 scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
 290 il diritto di esecuzione sulla directory che la contiene (torneremo in
 291 dettaglio sui permessi e gli attributi fra poco), se inoltre lo
 292 \textit{sticky} bit è settato occorrerà anche essere proprietari del file o
 293 proprietari della directory (o root, per cui nessuna delle restrizioni è
 294 applicata).
 295
 296 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
 297 della nome dalla directory e l'incremento/decremento del numero di riferimenti
 298 nell'inode deve essere una operazione atomica (cioè non interrompibile da
 299 altri) processi, per questo entrambe queste funzioni sono realizzate tramite
 300 una singola system call.
 301
 302 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
 303 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
 304   count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
 305 questo però si aggiunge una altra condizione, e cioè che non ci siano processi
 306 che abbiano detto file aperto. Come accennato questa proprietà viene spesso
 307 usata per essere sicuri di non lasciare file temporanei su disco in caso di
 308 crash dei programmi; la tecnica è quella di aprire il file e chiamare
 309 \texttt{unlink} subito dopo.
 310
 311 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
 312 \label{sec:filedir_cre_canc}
 313
 314 Al contrario di quanto avviene con altri unix in Linux non è possibile usare
 315 \texttt{unlink} sulle directory, per cancellare una directory si può usare la
 316 funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
 317 funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
 318 per cancellare un file o una directory (e funziona anche per i sistemi che non
 319 supportano i link diretti), che per i file è identica alla \texttt{unlink} e
 320 per le directory è identica alla \texttt{rmdir}:
 321
 322 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
 323   Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e
 324   \texttt{rmdir} per le directory.
 325
 326   La funzione restituisce zero in caso di successo e -1 per un errore, nel
 327   qual caso il file non viene toccato. Per i codici di errori vedi quanto
 328   riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}.
 329 \end{prototype}
 330
 331 Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il
 332 vantaggio nell'uso di questa funzione al posto della chiamata successiva di
 333 \texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in
 334 questo modo non c'è la possibilità che un processo che cerchi di accedere al
 335 nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante.
 336
 337 \begin{prototype}{stdio.h}
 338 {int rename(const char *oldpath, const char *newpath)}
 339   Rinomina un file, spostandolo fra directory diverse quando richiesto.
 340
 341   La funzione restituisce zero in caso di successo e -1 per un errore, nel
 342   qual caso il file non viene toccato. La variabile \texttt{errno} viene
 343   settata secondo i seguenti codici di errore:
 344   \begin{errlist}
 345   \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre
 346     \texttt{oldpath} non è una directory.
 347   \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
 348     stesso filesystem.
 349   \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e
 350     non vuota.
 351   \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da
 352     parte di qualche processo (come directory di lavoro o come root) o del
 353     sistema (come mount point).
 354   \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di
 355     \texttt{oldpath} o più in generale si è cercato di creare una directory
 356     come sottodirectory di se stessa.
 357   \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link
 358     consentiti o è una directory e la directory che contiene \texttt{newpath}
 359     ha già il massimo numero di link.
 360   \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory
 361     o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una
 362     directory.
 363   \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello
 364     spazio di indirizzi del processo.
 365   \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
 366     cui si vuole creare il nuovo link o una delle directory del pathname non
 367     consente la ricerca (permesso di esecuzione).
 368   \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o
 369     \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non
 370     consentono rispettivamente la cancellazione e la creazione del file, o il
 371     filesystem non supporta i link.
 372   \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo.
 373   \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
 374     simbolico spezzato.
 375   \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
 376     completare l'operazione.
 377   \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura.
 378   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
 379     pathname.
 380   \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la
 381     nuova voce.
 382   \end{errlist}
 383 \end{prototype}
 384
 385 \subsection{I link simbolici}
 386 \label{sec:filedir_sym_link}
 387
 388 Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
 389 funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
 390 in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
 391 tipo unix.  Inoltre in Linux non è consentito eseguire un link diretto ad una
 392 directory.
 393
 394 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
 395 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
 396 come avviene in altri sistemi operativi, dei file che contengono il
 397 semplicemente il riferimento ad un altro file (o directory). In questo modo è
 398 possibile effettuare link anche attraverso filesystem diversi e a directory, e
 399 pure a file che non esistono ancora.
 400
 401 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
 402 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
 403 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
 404 lettura del contenuto del medesimo e l'applicazione della funzione al file
 405 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
 406 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
 407 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
 408 alle informazioni del link invece che a quelle del file a cui esso fa
 409 riferimento.
 410
 411 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
 412 dichiarate nell'header file \texttt{unistd.h}.
 413
 414 \begin{prototype}{unistd.h}
 415 {int symlink(const char * oldname, const char * newname)}
 416   Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
 417   nome \texttt{newname}.
 418
 419   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
 420   di errore. La variabile \texttt{errno} viene settata secondo i codici di
 421   errore standard di accesso ai files (trattati in dettaglio in
 422   \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
 423   \begin{errlist}
 424   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
 425     già.
 426   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
 427     su un filesystem montato readonly.
 428   \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
 429     link è piena e non c'è ulteriore spazio disponibile.
 430   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
 431     \texttt{oldname} o di \texttt{newname}.
 432   \end{errlist}
 433 \end{prototype}
 434
 435 Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare
 436 un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
 437 questa funzione è la:
 438
 439 \begin{prototype}{unistd.h}
 440 {int readlink(const char * path, char * buff, size\_t size)}
 441   Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer
 442   \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
 443   carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
 444   piccolo per contenerla.
 445
 446   La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
 447   -1 per un errore, in caso di errore. La variabile \texttt{errno} viene
 448   settata secondo i codici di errore:
 449   \begin{errlist}
 450   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
 451     già.
 452   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
 453     su un filesystem montato readonly.
 454   \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
 455     link è piena e non c'è ulteriore spazio disponibile.
 456   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
 457     \texttt{oldname} o di \texttt{newname}.
 458   \end{errlist}
 459 \end{prototype}
 460
 461
 462 \section{La manipolazione delle caratteristiche dei files}
 463 \label{sec:filedir_infos}
 464
 465 Come spiegato in \secref{sec:filedir_file_handling} tutte le informazioni
 466 generali relative alle caratteristiche di ciascun file sono mantenute
 467 nell'inode. Vedremo in questa sezione come sia possibile accedervi usando la
 468 funzione \texttt{stat} ed esamineremo alcune funzioni utilizzabili per
 469 manipolare una parte di questa informazione. Tutto quello che invece riguarda
 470 il meccanismo di controllo di accesso ad i file e le relative funzioni di
 471 manipolazione sarà invece esaminanto in \secref{sec:filedir_access_control}.
 472
 473
 474 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
 475 \label{sec:filedir_stat}
 476
 477 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
 478 delle funzioni \texttt{stat}, questa è la funzione che il comando \texttt{ls}
 479 usa per poter stampare tutti i dati dei files; il prototipo della funzione è
 480 il seguente;
 481 \begin{prototype}{unistd.h}
 482 {int stat(const char *file\_name, struct stat *buf)}
 483
 484   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
 485   di errore \texttt{errno} viene settato ai valori:
 486   \begin{errlist}
 487   \item \texttt{EACCESS} Non c'è il permesso di accedere al file.
 488   \item \texttt{ENOTDIR} Una componente del pathname non è una directory.
 489   \item \texttt{EMLOOP} Ci sono troppi link simbolici nel pathname.
 490   \item \texttt{EFAULT} I puntatori usati sono fuori dallo spazio di indirizzi
 491     del processo.
 492   \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
 493     completare l'operazione.
 494   \item \texttt{ENAMETOOLONG} Il filename è troppo lungo.
 495   \end{errlist}
 496 \end{prototype}
 497
 498 La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in
 499 generale dipende dall'implementazione, la versione usata da Linux è mostrata
 500 in \nfig, così come riportata dalla man page (in realtà la definizione
 501 effettivamente usata nel kernel dipende dall'archietettura e ha altri campi
 502 riservati per estensioni come tempo più precisi, o per il padding dei campi).
 503
 504 \begin{figure}[!htbp]
 505   \footnotesize
 506   \begin{lstlisting}{}
 507 struct stat {
 508     dev_t         st_dev;      /* device */
 509     ino_t         st_ino;      /* inode */
 510     mode_t        st_mode;     /* protection */
 511     nlink_t       st_nlink;    /* number of hard links */
 512     uid_t         st_uid;      /* user ID of owner */
 513     gid_t         st_gid;      /* group ID of owner */
 514     dev_t         st_rdev;     /* device type (if inode device) */
 515     off_t         st_size;     /* total size, in bytes */
 516     unsigned long st_blksize;  /* blocksize for filesystem I/O */
 517     unsigned long st_blocks;   /* number of blocks allocated */
 518     time_t        st_atime;    /* time of last access */
 519     time_t        st_mtime;    /* time of last modification */
 520     time_t        st_ctime;    /* time of last change */
 521 };
 522   \end{lstlisting}
 523   \caption{La struttura \texttt{stat} per la lettura delle informazioni dei
 524     file}
 525   \label{fig:sock_sa_gen_struct}
 526 \end{figure}
 527
 528 Si noti come i vari membri della struttura siano specificati come tipi nativi
 529 del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
 530 \texttt{sys/types.h})
 531
 532
 533
 534 \subsection{I tipi di file}
 535 \label{sec:filedir_file_types}
 536
 537 Come riportato in \tabref{tab:fileintr_file_types} in linux oltre ai file e
 538 alle directory esistono vari altri oggetti che possono stare su un filesystem;
 539 il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode},
 540 dato che il valore numerico può variare a seconda delle implementazioni
 541
 542
 543 \subsection{La dimensione dei file}
 544 \label{sec:filedir_file_size}
 545
 546 \subsection{I tempi dei file}
 547 \label{sec:filedir_file_times}
 548
 549 \subsection{La funzione \texttt{utime}}
 550 \label{sec:filedir_utime}
 551
 552
 553
 554
 555 \section{Il controllo di accesso ai file}
 556 \label{sec:filedir_access_control}
 557
 558
 559 \subsection{I flag \texttt{suid} e \texttt{sgid}}
 560 \label{sec:filedir_suid_sgid}
 561
 562 \subsection{La titolarità di nuovi files e directory}
 563 \label{sec:filedir_ownership}
 564
 565 \subsection{La funzione \texttt{access}}
 566 \label{sec:filedir_access}
 567
 568 \subsection{La funzione \texttt{umask}}
 569 \label{sec:filedir_umask}
 570
 571 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
 572 \label{sec:filedir_chmod}
 573
 574 \subsection{Il flag \texttt{sticky}}
 575 \label{sec:filedir_sticky}
 576
 577 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
 578 \label{sec:filedir_chown}
 579
 580
 581 \section{La manipolazione delle directories}
 582 \label{sec:filedir_dir_handling}
 583
 584 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
 585 \label{sec:filedir_dir_creat_rem}
 586
 587 Per creare una nuova directory si può usare la seguente funzione, omonima
 588 dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati
 589 programma deve includere il file \texttt{sys/types.h}.
 590
 591 \begin{prototype}{sys/stat.h}
 592 {int mkdir (const char * dirname, mode\_t mode)}
 593   Questa funzione crea una nuova directory vuota con il nome indicato da
 594   \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
 595   può essere indicato con il pathname assoluto o relativo.
 596
 597   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
 598   di errore \texttt{errno} viene settata secondo i codici di errore standard
 599   di accesso ai files (trattati in dettaglio in
 600   \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
 601   \begin{errlist}
 602   \item \texttt{EACCESS}
 603     Non c'è il permesso di scrittura per la directory in cui si vuole inserire
 604     la nuova directory.
 605   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già.
 606   \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
 607     contiene troppi file. Sotto Linux questo normalmente non avviene perché il
 608     filesystem standard consente la creazione di un numero di file maggiore di
 609     quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
 610     fare anche con filesystem di altri sistemi questo errore può presentarsi.
 611   \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
 612     la nuova directory.
 613   \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
 614     directory è su un filesystem montato readonly.
 615   \end{errlist}
 616 \end{prototype}
 617
 618
 619 \subsection{Accesso alle directory}
 620 \label{sec:filedir_dir_read}
 621
 622 Benché le directory siano oggetti del filesystem come tutti gli altri non ha
 623 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
 624 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
 625 contengono o ricerche sui medesimi.
 626
 627 Per accedere al contenuto delle directory si usano i cosiddetti
 628 \textit{directory streams} (chiamati così per l'analogia con i file stream);
 629 la funzione \texttt{opendir} apre uno di questi stream e la funzione
 630 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
 631 \textit{directory entries} (da distinguersi da quelle della cache di cui
 632 parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura
 633 \texttt{struct dirent}.
 634
 635
 636 \subsection{La directory di lavoro}
 637 \label{sec:filedir_work_dir}
 638
 639 A ciascun processo è associato ad una directory nel filesystem che è chiamata
 640 directory corrente o directory di lavoro (\textit{current working directory})
 641 che è quella a cui si fa riferimento quando un filename è espresso in forma
 642 relativa (relativa appunto a questa directory).
 643
 644 Quando un utente effettua il login questa directory viene settata alla
 645 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
 646 della shell consente di cambiarla a piacere, spostandosi da una directory ad
 647 un'altra.  Siccome la directory corrente resta la stessa quando viene creato
 648 un processo figlio, la directory corrente della shell diventa anche la
 649 directory corrente di qualunque comando da essa lanciato.
 650
 651 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
 652 corrente.
 653
 654 \begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
 655   Restituisce il filename completo della directory di lavoro corrente nella
 656   stringa puntata da \texttt{buffer}, che deve essere precedentemente
 657   allocata, per una dimensione massima di \texttt{size}. Si può anche
 658   specificare un puntatore nullo come \textit{buffer}, nel qual caso la
 659   stringa sarà allocata automaticamente per una dimensione pari a
 660   \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
 661   del pathname altrimenti. In questo caso si deve ricordare di disallocare la
 662   stringa una volta cessato il suo utilizzo.
 663
 664   La funzione restituisce il puntatore \texttt{buffer} se riesce,
 665   \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
 666   \texttt{errno} è settata con i seguenti codici di errore:
 667   \begin{errlist}
 668   \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
 669     è nullo.
 670   \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
 671     lunghezza del pathname.
 672   \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei
 673     componenti del pathname (cioè su una delle directory superiori alla
 674     corrente).
 675   \end{errlist}
 676 \end{prototype}
 677
 678 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
 679 fatta per compatibilità all'indietro con BSD, che non consente di specificare
 680 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
 681 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
 682 \secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
 683 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
 684 contenere il nome del file, e questa è la ragione principale per cui questa
 685 funzione è deprecata.
 686
 687 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
 688 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
 689 differenza che essa ritorna il valore della variabile di ambiente
 690 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
 691 riferimenti simbolici.
 692
 693 Come già detto in unix anche le directory sono file, è possibile pertanto
 694 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
 695 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
 696 per cambiare directory di lavoro.
 697
 698 \begin{prototype}{unistd.h}{int chdir (const char * pathname)}
 699   Come dice il nome (che significa \textit{change directory}) questa funzione
 700   serve a cambiare la directory di lavoro a quella specificata dal pathname
 701   contenuto nella stringa \texttt{pathname}.
 702 \end{prototype}
 703
 704 \begin{prototype}{unistd.h}{int fchdir (int filedes)}
 705   Analoga alla precedente, ma usa un file descriptor invece del pathname.
 706
 707   Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
 708   errore, in caso di errore \texttt{errno} viene settata secondo i codici di
 709   errore standard di accesso ai files (trattati in dettaglio in
 710   \secref{sec:filedir_access_control}) ai quali si aggiunge il codice
 711   \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
 712   una directory.
 713 \end{prototype}
 714
 715
 716
 717
 718 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
 719 %cosiddetto \textit{inode}; questo conterrà informazioni come il
 720 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
 721 %completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
 722 %\secref{sec:file_times}).
 723