+\subsection{Accesso alle directory}
+\label{sec:file_dir_read}
+
+Benché le directory siano oggetti del filesystem come tutti gli altri non ha
+ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
+poterne leggere il contenuto ad esempio per fare la lista dei file che esse
+contengono o ricerche sui medesimi. Solo il kernel può scrivere direttamente
+in una directory (onde evitare inconsistenze all'interno del filesystem), i
+processi devono creare i file usando le apposite funzioni.
+
+Per accedere al contenuto delle directory si usano i cosiddetti
+\textit{directory streams} (chiamati così per l'analogia con i file stream di
+\capref{che:file_std_interface}); la funzione \func{opendir} apre uno di
+questi stream e la funzione \func{readdir} legge il contenuto della directory,
+i cui elementi sono le \textit{directory entry} (da distinguersi da quelle
+della cache di cui parlavamo in \secref{sec:file_vfs}) in una opportuna
+struttura \var{struct dirent}.
+
+(NdA Il resto va scritto!!! É noioso e lo farò più avanti).
+
+
+\subsection{La directory di lavoro}
+\label{sec:file_work_dir}
+
+A ciascun processo è associato ad una directory nel filesystem che è chiamata
+directory corrente o directory di lavoro (\textit{current working directory})
+che è quella a cui si fa riferimento quando un filename è espresso in forma
+relativa, dove il relativa fa riferimento appunto a questa directory.
+
+Quando un utente effettua il login questa directory viene settata alla
+\textit{home directory} del suo account. Il comando \cmd{cd} della shell
+consente di cambiarla a piacere, spostandosi da una directory ad un'altra, il
+comando \cmd{pwd} la stampa sul terminale. Siccome la directory corrente
+resta la stessa quando viene creato un processo figlio (vedi
+\secref{sec:proc_fork}), la directory corrente della shell diventa anche la
+directory corrente di qualunque comando da essa lanciato.
+
+In genere il kernel tiene traccia per ciascun processo dell'inode della
+directory di lavoro corrente, per ottenere il pathname occorre usare una
+apposita funzione di libreria, \func{getcwd}, il cui prototipo è:
+\begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}
+ Restituisce il filename completo della directory di lavoro corrente nella
+ stringa puntata da \var{buffer}, che deve essere precedentemente
+ allocata, per una dimensione massima di \var{size}.
+
+ \bodydesc{La funzione restituisce il puntatore \var{buffer} se riesce,
+ \macro{NULL} se fallisce, in quest'ultimo caso la variabile
+ \var{errno} è settata con i seguenti codici di errore:
+ \begin{errlist}
+ \item[\macro{EINVAL}] L'argomento \var{size} è zero e \var{buffer} non
+ è nullo.
+ \item[\macro{ERANGE}] L'argomento \var{size} è più piccolo della
+ lunghezza del pathname.
+ \item[\macro{EACCESS}] Manca il permesso di lettura o di ricerca su uno dei
+ componenti del pathname (cioè su una delle directory superiori alla
+ corrente).
+ \end{errlist}}
+\end{prototype}
+
+Il buffer deve essere sufficientemente lungo da poter contenere il pathname
+completo più lo zero di terminazione della stringa. Qualora esso ecceda le
+dimensioni specificate con \var{size} la funzione restituisce un errore. Si
+può anche specificare un puntatore nullo come \var{buffer}\footnote{questa è
+ una estensione allo standard POSIX.1, supportata da Linux}, nel qual caso la
+stringa sarà allocata automaticamente per una dimensione pari a \var{size}
+qualora questa sia diversa da zero, o della lunghezza esatta del pathname
+altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una
+volta cessato il suo utilizzo.
+
+Di questa funzione esiste una versione \code{char *getwd(char *buffer)}
+fatta per compatibilità all'indietro con BSD, che non consente di specificare
+la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
+dimensione superiore a \macro{PATH\_MAX} (di solito 256 byte, vedi
+\secref{sec:sys_limits}); il problema è che in Linux non esiste una dimensione
+superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
+contenere il nome del file, e questa è la ragione principale per cui questa
+funzione è deprecata.
+
+Una seconda funzione simile è \code{char *get\_current\_dir\_name(void)} che è
+sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la sola
+differenza che essa ritorna il valore della variabile di ambiente \macro{PWD},
+che essendo costruita dalla shell può contenere anche dei riferimenti
+simbolici; nel caso di \func{getcwd} infatti, essendo il pathname ricavato
+risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
+passaggio attraverso eventuali pathname.
+
+Altre due funzioni, \func{chdir} e \func{fchdir}, vengono usate, come dice il
+nome (che deriva da \textit{change directory}), per cambiare la directory di
+lavoro corrente. Dato che anche le directory sono file, è possibile riferirsi
+ad esse anche tramite il file descriptor dell'interfaccia a basso livello, e
+non solo tramite il filename, i prototipi di queste funzioni sono:
+\begin{functions}
+ \headdecl{unistd.h}
+ \funcdecl{int chdir(const char *path)}
+ Cambia la directory di lavoro corrente a quella specificata dal pathname
+ contenuto nella stringa \var{path}.
+
+ \funcdecl{int fchdir(int fd)} Analoga alla precedente, ma usa un file
+ descriptor invece del pathname.
+
+ \bodydesc{Entrambe le funzioni restituiscono zero in caso di successo
+ e -1 per un errore, in caso di errore \var{errno} viene settata per
+ \func{chdir} ai valori:
+ \begin{errlist}
+ \item[\macro{ENOTDIR}] Uno dei componenti di \param{path} non è una
+ directory.
+ \item[\macro{EACCESS}] Manca il permesso di ricerca su uno dei componenti di
+ \param{path}.
+ \end{errlist}
+ ed inoltre \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT},
+ \macro{ENOMEM}, \macro{ELOOP} e \macro{EIO}. Per \func{fchdir} invece gli
+ errori sono \macro{EBADF} e \macro{EACCES}.}
+\end{functions}
+
+
+
+\subsection{I file temporanei}
+\label{sec:file_temp_file}
+
+Un'altra serie di funzioni definite dalle librerie standard del C sono quelle
+che riguardano la creazione di file temporanei.
+
+
+
+
+\section{La manipolazione delle caratteristiche dei files}
+\label{sec:file_infos}
+
+Come spiegato in \secref{sec:file_filesystem} tutte le informazioni
+generali relative alle caratteristiche di ciascun file, a partire dalle
+informazioni relative al controllo di accesso, sono mantenute nell'inode.
+
+Vedremo in questa sezione come sia possibile leggere tutte queste informazioni
+usando la funzione \func{stat}, che permette l'accesso a tutti i dati
+memorizzati nell'inode; esamineremo poi le varie funzioni usate per manipolare
+tutte queste informazioni (eccetto quelle che riguardano la gestione del
+controllo di accesso, trattate in in \secref{sec:file_access_control}).
+
+
+\subsection{Le funzioni \func{stat}, \func{fstat} e \func{lstat}}
+\label{sec:file_stat}
+
+La lettura delle informazioni relative ai file è fatta attraverso la famiglia
+delle funzioni \func{stat}; questa è la funzione che ad esempio usa il comando
+\cmd{ls} per poter ottenere e mostrare tutti i dati dei files. I prototipi di
+queste funzioni sono i seguenti:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/stat.h}
+ \headdecl{unistd.h}
+
+ \funcdecl{int stat(const char *file\_name, struct stat *buf)} Legge le
+ informazione del file specificato da \var{file\_name} e le inserisce in
+ \var{buf}.
+
+ \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
+ \func{stat} eccetto che se il \var{file\_name} è un link simbolico vengono
+ lette le informazioni relativa ad esso e non al file a cui fa riferimento.
+
+ \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
+ eccetto che si usa con un file aperto, specificato tramite il suo file
+ descriptor \var{filedes}.
+
+ \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
+ un errore, in caso di errore \var{errno} può assumere uno dei
+ valori: \macro{EBADF}, \macro{ENOENT}, \macro{ENOTDIR},
+ \macro{ELOOP}, \macro{EFAULT}, \macro{EACCESS}, \macro{ENOMEM},
+ \macro{ENAMETOOLONG}.}
+\end{functions}
+
+La struttura \var{stat} è definita nell'header \file{sys/stat.h} e in
+generale dipende dall'implementazione, la versione usata da Linux è mostrata
+in \nfig, così come riportata dalla man page (in realtà la definizione
+effettivamente usata nel kernel dipende dall'architettura e ha altri campi
+riservati per estensioni come tempi più precisi, o per il padding dei campi).
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+struct stat {
+ dev_t st_dev; /* device */
+ ino_t st_ino; /* inode */
+ mode_t st_mode; /* protection */
+ nlink_t st_nlink; /* number of hard links */
+ uid_t st_uid; /* user ID of owner */
+ gid_t st_gid; /* group ID of owner */
+ dev_t st_rdev; /* device type (if inode device) */
+ off_t st_size; /* total size, in bytes */
+ unsigned long st_blksize; /* blocksize for filesystem I/O */
+ unsigned long st_blocks; /* number of blocks allocated */
+ time_t st_atime; /* time of last access */
+ time_t st_mtime; /* time of last modification */
+ time_t st_ctime; /* time of last change */
+};
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \var{stat} per la lettura delle informazioni dei
+ file}
+ \label{fig:file_stat_struct}
+\end{figure}
+
+Si noti come i vari membri della struttura siano specificati come tipi nativi
+del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
+\file{sys/types.h}).
+
+
+\subsection{I tipi di file}
+\label{sec:file_types}
+
+Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e