+\subsection{La directory di lavoro}
+\label{sec:file_work_dir}
+
+\index{directory~di~lavoro|(}
+
+Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
+directory nell'albero dei file,\footnote{questa viene mantenuta all'interno
+ dei dati della sua \kstruct{task\_struct} (vedi
+ fig.~\ref{fig:proc_task_struct}), più precisamente nel campo \texttt{pwd}
+ della sotto-struttura \kstruct{fs\_struct}.} che è chiamata
+\textsl{directory corrente} o \textsl{directory di lavoro} (in inglese
+\textit{current working directory}). La directory di lavoro è quella da cui
+si parte quando un \textit{pathname} è espresso in forma relativa, dove il
+``\textsl{relativa}'' fa riferimento appunto a questa directory.
+
+Quando un utente effettua il login, questa directory viene impostata 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 di lavoro
+resta la stessa quando viene creato un processo figlio (vedi
+sez.~\ref{sec:proc_fork}), la directory di lavoro della shell diventa anche la
+directory di lavoro di qualunque comando da essa lanciato.
+
+Dato che è il kernel che tiene traccia dell'\textit{inode} della directory di
+lavoro di ciascun processo, per ottenerne il \textit{pathname} occorre usare
+una apposita funzione, \funcd{getcwd},\footnote{con Linux \func{getcwd} è una
+ \textit{system call} dalla versione 2.1.9, in precedenza il valore doveva
+ essere ottenuto tramite il filesystem \texttt{/proc} da
+ \procfile{/proc/self/cwd}.} il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{char *getcwd(char *buffer, size\_t size)}
+\fdesc{Legge il \textit{pathname} della directory di lavoro corrente.}
+}
+{La funzione ritorna il puntatore a \param{buffer} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] manca il permesso di lettura o di attraversamento su
+ uno dei componenti del \textit{pathname} (cioè su una delle directory
+ superiori alla corrente).
+ \item[\errcode{EINVAL}] l'argomento \param{size} è zero e \param{buffer} non
+ è nullo.
+ \item[\errcode{ENOENT}] la directory di lavoro è stata eliminata.
+ \item[\errcode{ERANGE}] l'argomento \param{size} è più piccolo della
+ lunghezza del \textit{pathname}.
+ \end{errlist}
+ ed inoltre \errcode{EFAULT} ed \errcode{ENOMEM} nel loro significato
+ generico.}
+\end{funcproto}
+
+La funzione restituisce il \textit{pathname} completo della directory di
+lavoro corrente nella stringa puntata da \param{buffer}, che deve essere
+precedentemente allocata, per una dimensione massima di \param{size}. Il
+buffer deve essere sufficientemente largo da poter contenere il
+\textit{pathname} completo più lo zero di terminazione della stringa. Qualora
+esso ecceda le dimensioni specificate con \param{size} la funzione restituisce
+un errore.
+
+A partire dal kernel Linux 2.6.36 il nome può avere come prefisso la stringa
+\texttt{(unreachable)} se la directory di lavoro resta fuori dalla directory
+radice del processo dopo un \func{chroot} (torneremo su questi argomenti in
+sez.~\ref{sec:file_chroot}); pertanto è sempre opportuno controllare il primo
+carattere della stringa restituita dalla funzione per evitare di interpretare
+mare un \textit{pathname} irraggiungibile.
+
+Come estensione allo standard POSIX.1, supportata da Linux e dalla
+\acr{glibc}, si può anche specificare un puntatore nullo come \param{buffer}
+nel qual caso la stringa sarà allocata automaticamente per una dimensione pari
+a \param{size} qualora questa sia diversa da zero, o della lunghezza esatta
+del \textit{pathname} altrimenti. In questo caso ci si deve ricordare di
+disallocare la stringa con \func{free} una volta cessato il suo utilizzo.
+
+Un uso comune di \func{getcwd} è quello di salvarsi la directory di lavoro
+all'avvio del programma per poi potervi tornare in un tempo successivo, un
+metodo alternativo più veloce, se non si è a corto di file descriptor, è
+invece quello di aprire all'inizio la directory corrente (vale a dire
+``\texttt{.}'') e tornarvi in seguito con \func{fchdir}.
+
+Di questa funzione esiste una versione alternativa per compatibilità
+all'indietro con BSD, \funcm{getwd}, che non prevede l'argomento \param{size}
+e quindi non consente di specificare la dimensione di \param{buffer} che
+dovrebbe essere allocato in precedenza ed avere una dimensione sufficiente
+(per BSD maggiore \const{PATH\_MAX}, che di solito 256 byte, vedi
+sez.~\ref{sec:sys_limits}). Il problema è che su Linux non esiste una
+dimensione superiore per la lunghezza di un \textit{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, e non la tratteremo.
+
+Una seconda funzione usata per ottenere la directory di lavoro è
+\funcm{get\_current\_dir\_name} (la funzione è una estensione GNU e presente
+solo nella \acr{glibc}) che non prende nessun argomento ed è sostanzialmente
+equivalente ad una \code{getcwd(NULL, 0)}, con la differenza che se
+disponibile essa ritorna il valore della variabile di ambiente \envvar{PWD},
+che essendo costruita dalla shell può contenere un \textit{pathname}
+comprendente anche dei collegamenti simbolici. Usando \func{getcwd} infatti,
+essendo il \textit{pathname} ricavato risalendo all'indietro l'albero della
+directory, si perderebbe traccia di ogni passaggio attraverso eventuali
+collegamenti simbolici.
+
+Per cambiare la directory di lavoro si può usare la funzione di sistema
+\funcd{chdir}, equivalente del comando di shell \cmd{cd}, il cui nome sta
+appunto per \textit{change directory}, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int chdir(const char *pathname)}
+\fdesc{Cambia la directory di lavoro per \textit{pathname}.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] manca il permesso di ricerca su uno dei componenti
+ di \param{pathname}.
+ \item[\errcode{ENAMETOOLONG}] il nome indicato in \param{path} è troppo lungo.
+ \item[\errcode{ENOTDIR}] non si è specificata una directory.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP}, \errval{ENOENT} e
+ \errval{ENOMEM} nel loro significato generico.}
+\end{funcproto}
+
+La funzione cambia la directory di lavoro in \param{pathname} ed
+ovviamente \param{pathname} deve indicare una directory per la quale si hanno
+i permessi di accesso.
+
+Dato che ci si può riferire ad una directory anche tramite un file descriptor,
+per cambiare directory di lavoro è disponibile anche la funzione di sistema
+\funcd{fchdir}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int fchdir(int fd)}
+\fdesc{Cambia la directory di lavoro per file descriptor.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà i valori \errval{EBADF} o \errval{EACCES} nel loro
+ significato generico.}
+\end{funcproto}
+
+La funzione è identica a \func{chdir}, ma prende come argomento un file
+descriptor \param{fd} invece di un \textit{pathname}. Anche in questo
+caso \param{fd} deve essere un file descriptor valido che fa riferimento ad
+una directory. Inoltre l'unico errore di accesso possibile (tutti gli altri
+sarebbero occorsi all'apertura di \param{fd}), è quello in cui il processo non
+ha il permesso di attraversamento alla directory specificata da \param{fd}.
+
+\index{directory~di~lavoro|)}
+
+
+\subsection{La creazione dei \textsl{file speciali}}
+\label{sec:file_mknod}
+
+\index{file!di~dispositivo|(}
+\index{file!speciali|(}
+
+Finora abbiamo parlato esclusivamente di file, directory e collegamenti
+simbolici, ma in sez.~\ref{sec:file_file_types} abbiamo visto che il sistema
+prevede anche degli altri tipi di file, che in genere vanno sotto il nome
+generico di \textsl{file speciali}, come i file di dispositivo, le
+\textit{fifo} ed i socket.
+
+La manipolazione delle caratteristiche di questi file speciali, il cambiamento
+di nome o la loro cancellazione può essere effettuata con le stesse funzioni
+che operano sugli altri file, ma quando li si devono creare sono necessarie,
+come per le directory, delle funzioni apposite. La prima di queste è la
+funzione di sistema \funcd{mknod}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/stat.h}
+\fhead{fcntl.h}
+\fhead{unistd.h}
+\fdecl{int mknod(const char *pathname, mode\_t mode, dev\_t dev)}
+\fdesc{Crea un file speciale sul filesystem.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EEXIST}] \param{pathname} esiste già o è un collegamento
+ simbolico.
+ \item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
+ \textit{fifo}, un socket o un dispositivo.
+ \item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare
+ l'\texttt{inode}, o il filesystem su cui si è cercato di
+ creare \param{pathname} non supporta l'operazione.
+ \end{errlist}
+ ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{ELOOP},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOSPC},
+ \errval{ENOTDIR} e \errval{EROFS} nel loro significato generico.}
+\end{funcproto}
+
+La funzione permette di creare un \textit{inode} di tipo generico sul
+filesystem, e viene in genere utilizzata per creare i file di dispositivo, ma
+si può usare anche per creare qualunque tipo di file speciale ed anche file
+regolari. L'argomento \param{mode} specifica sia il tipo di file che si vuole
+creare che i relativi permessi, secondo i valori riportati in
+tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR aritmetico. I
+permessi sono comunque modificati nella maniera usuale dal valore di
+\textit{umask} (si veda sez.~\ref{sec:file_perm_management}).
+
+Per il tipo di file può essere specificato solo uno fra i seguenti valori:
+\const{S\_IFREG} per un file regolare (che sarà creato vuoto),
+\const{S\_IFBLK} per un dispositivo a blocchi, \const{S\_IFCHR} per un
+dispositivo a caratteri, \const{S\_IFSOCK} per un socket e \const{S\_IFIFO}
+per una \textit{fifo};\footnote{con Linux la funzione non può essere usata per
+ creare directory o collegamenti simbolici, si dovranno usare le funzioni
+ \func{mkdir} e \func{symlink} a questo dedicate.} un valore diverso
+comporterà l'errore \errcode{EINVAL}. Inoltre \param{pathname} non deve
+esistere, neanche come collegamento simbolico.
+
+Qualora si sia specificato in \param{mode} un file di dispositivo (vale a dire
+o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere
+usato per indicare a quale dispositivo si fa riferimento, altrimenti il suo
+valore verrà ignorato. Solo l'amministratore può creare un file di
+dispositivo usando questa funzione (il processo deve avere la capacità
+\const{CAP\_MKNOD}), ma in Linux\footnote{questo è un comportamento specifico
+ di Linux, la funzione non è prevista dallo standard POSIX.1 originale,
+ mentre è presente in SVr4 e 4.4BSD, ma esistono differenze nei comportamenti
+ e nei codici di errore, tanto che questa è stata introdotta in POSIX.1-2001
+ con una nota che la definisce portabile solo quando viene usata per creare
+ delle \textit{fifo}, ma comunque deprecata essendo utilizzabile a tale scopo
+ la specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di
+una \textit{fifo} o di un socket è consentito anche agli utenti normali.
+
+Gli \textit{inode} creati con \func{mknod} apparterranno al proprietario e al
+gruppo del processo (usando \ids{UID} e \ids{GID} del gruppo effettivo) che li
+ha creati a meno non sia presente il bit \acr{sgid} per la directory o sia
+stata attivata la semantica BSD per il filesystem (si veda
+sez.~\ref{sec:file_ownership_management}) in cui si va a creare
+l'\textit{inode}, nel qual caso per il gruppo verrà usato il \ids{GID} del
+proprietario della directory.
+
+\itindbeg{major~number}
+\itindbeg{minor~number}
+
+Nella creazione di un file di dispositivo occorre poi specificare
+correttamente il valore di \param{dev}; questo infatti è di tipo
+\type{dev\_t}, che è un tipo primitivo (vedi
+tab.~\ref{tab:intro_primitive_types}) riservato per indicare un
+\textsl{numero} di dispositivo. Il kernel infatti identifica ciascun
+dispositivo con un valore numerico, originariamente questo era un intero a 16
+bit diviso in due parti di 8 bit chiamate rispettivamente \textit{major
+ number} e \textit{minor number}, che sono poi i due numeri mostrati dal
+comando \texttt{ls -l} al posto della dimensione quando lo si esegue su un
+file di dispositivo.
+
+Il \textit{major number} identifica una classe di dispositivi (ad esempio la
+seriale, o i dischi IDE) e serve in sostanza per indicare al kernel quale è il
+modulo che gestisce quella classe di dispositivi. Per identificare uno
+specifico dispositivo di quella classe (ad esempio una singola porta seriale,
+o uno dei dischi presenti) si usa invece il \textit{minor number}. L'elenco
+aggiornato di questi numeri con le relative corrispondenze ai vari dispositivi
+può essere trovato nel file \texttt{Documentation/devices.txt} allegato alla
+documentazione dei sorgenti del kernel.
+
+Data la crescita nel numero di dispositivi supportati, ben presto il limite
+massimo di 256 si è rivelato troppo basso, e nel passaggio dai kernel della
+serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo
+\type{dev\_t}, con delle dimensioni passate a 12 bit per il \textit{major
+ number} e 20 bit per il \textit{minor number}. La transizione però ha
+comportato il fatto che \type{dev\_t} è diventato un tipo opaco, e la
+necessità di specificare il numero tramite delle opportune macro, così da non
+avere problemi di compatibilità con eventuali ulteriori estensioni.
+
+Le macro sono definite nel file \headfiled{sys/sysmacros.h},\footnote{se si
+ usa la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
+ versioni specifiche di questa libreria, \macrod{gnu\_dev\_major},
+ \macrod{gnu\_dev\_minor} e \macrod{gnu\_dev\_makedev} che si possono usare
+ direttamente, al costo di una minore portabilità.} che viene automaticamente
+incluso quando si include \headfile{sys/types.h}. Si possono pertanto ottenere
+i valori del \textit{major number} e \textit{minor number} di un dispositivo
+rispettivamente con le macro \macro{major} e \macro{minor}:
+
+{\centering
+\vspace{3pt}
+\begin{funcbox}{
+\fhead{sys/types.h}
+\fdecl{int \macrod{major}(dev\_t dev)}
+\fdesc{Restituisce il \textit{major number} del dispositivo \param{dev}.}
+\fdecl{int \macrod{minor}(dev\_t dev)}
+\fdesc{Restituisce il \textit{minor number} del dispositivo \param{dev}.}
+}
+\end{funcbox}
+}
+
+\noindent mentre una volta che siano noti \textit{major number} e
+\textit{minor number} si potrà costruire il relativo identificativo con la
+macro \macro{makedev}:
+
+{\centering
+\vspace{3pt}
+\begin{funcbox}{
+\fhead{sys/types.h}
+\fdecl{dev\_t \macrod{makedev}(int major, int minor)}
+\fdesc{Dati \textit{major number} e \textit{minor number} restituisce
+ l'identificativo di un dispositivo.}
+}
+\end{funcbox}
+}
+
+
+\itindend{major~number}
+\itindend{minor~number}
+\index{file!di~dispositivo|)}
+
+Dato che la funzione di sistema \func{mknod} presenta diverse varianti nei
+vari sistemi unix-like, lo standard POSIX.1-2001 la dichiara portabile solo in
+caso di creazione delle \textit{fifo}, ma anche in questo caso alcune
+combinazioni degli argomenti restano non specificate, per cui nello stesso
+standard è stata introdotta una funzione specifica per creare una
+\textit{fifo} deprecando l'uso di \func{mknod} a tale riguardo. La funzione è
+\funcd{mkfifo} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/stat.h}
+\fdecl{int mkfifo(const char *pathname, mode\_t mode)}
+\fdesc{Crea una \textit{fifo}.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà \errval{EACCES}, \errval{EEXIST},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOSPC}, \errval{ENOTDIR} e
+ \errval{EROFS} nel loro significato generico.}
+\end{funcproto}
+
+La funzione crea la \textit{fifo} \param{pathname} con i
+permessi \param{mode}. Come per \func{mknod} il file \param{pathname} non deve
+esistere (neanche come collegamento simbolico); al solito i permessi
+specificati da \param{mode} vengono modificati dal valore di \textit{umask}
+(vedi sez.~\ref{sec:file_perm_management}).
+
+\index{file!speciali|)}
+
+
+\subsection{I file temporanei}
+\label{sec:file_temp_file}
+
+In molte occasioni è utile poter creare dei file temporanei; benché la cosa
+sembri semplice, in realtà il problema è più sottile di quanto non appaia a
+prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
+creare il file dopo aver controllato che questo non esista, nel momento fra il
+controllo e la creazione si ha giusto lo spazio per una possibile \textit{race
+ condition} (si ricordi quanto visto in sez.~\ref{sec:proc_race_cond}).
+
+\itindbeg{symlink~attack}
+
+Molti problemi di sicurezza derivano proprio da una creazione non accorta di
+file temporanei che lascia aperta questa \textit{race condition}. Un
+attaccante allora potrà sfruttarla con quello che viene chiamato
+``\textit{symlink attack}'' dove nell'intervallo fra la generazione di un nome
+e l'accesso allo stesso, viene creato un collegamento simbolico con quel nome
+verso un file diverso, ottenendo, se il programma sotto attacco ne ha la
+capacità, un accesso privilegiato.\footnote{dal kernel 3.6 sono state
+ introdotte delle contromisure, illustrate in
+ sez.~\ref{sec:procadv_security_misc}, che rendono impraticabili questo tipo
+ di attacchi, ma questa non è una buona scusa per ignorare il problema.}
+
+\itindend{symlink~attack}
+
+La \acr{glibc} provvede varie funzioni per generare nomi di file temporanei,
+di cui si abbia certezza di unicità al momento della generazione; storicamente
+la prima di queste funzioni create a questo scopo era
+\funcd{tmpnam},\footnote{la funzione è stata deprecata nella revisione
+ POSIX.1-2008 dello standard POSIX.} il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{char *tmpnam(char *string)}
+\fdesc{Genera un nome univoco per un file temporaneo.}
+}
+{La funzione ritorna il puntatore alla stringa con il nome in caso di successo
+ e \val{NULL} in caso di fallimento, non sono definiti errori.}
+\end{funcproto}
+
+La funzione restituisce il puntatore ad una stringa contente un nome di file
+valido e non esistente al momento dell'invocazione. Se si è passato come
+argomento \param{string} un puntatore non nullo ad un buffer di caratteri
+questo deve essere di dimensione \constd{L\_tmpnam} ed il nome generato vi
+verrà copiato automaticamente, altrimenti il nome sarà generato in un buffer
+statico interno che verrà sovrascritto ad una chiamata successiva. Successive
+invocazioni della funzione continueranno a restituire nomi unici fino ad un
+massimo di \constd{TMP\_MAX} volte, limite oltre il quale il comportamento è
+indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
+specificata dalla costante \constd{P\_tmpdir}.\footnote{le costanti
+ \const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
+ \headfile{stdio.h}.}
+
+Di questa funzione esiste una versione rientrante, \funcm{tmpnam\_r}, che non
+fa nulla quando si passa \val{NULL} come argomento. Una funzione simile,
+\funcd{tempnam}, permette di specificare un prefisso per il file
+esplicitamente, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{char *tempnam(const char *dir, const char *pfx)}
+\fdesc{Genera un nome univoco per un file temporaneo.}
+}
+{La funzione ritorna il puntatore alla stringa con il nome in caso di successo
+ e \val{NULL} per un errore, nel qual caso \var{errno} potrà assumere solo il
+ valore \errval{ENOMEM} qualora fallisca l'allocazione della stringa.}
+\end{funcproto}
+
+La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
+per cui è sempre rientrante, occorre però ricordarsi di disallocare con
+\code{free} il puntatore che restituisce. L'argomento \param{pfx} specifica
+un prefisso di massimo 5 caratteri per il nome provvisorio. La funzione
+assegna come directory per il file temporaneo, verificando che esista e sia
+accessibile, la prima valida fra le seguenti:
+\begin{itemize*}
+\item la variabile di ambiente \envvar{TMPDIR} (non ha effetto se non è
+ definita o se il programma chiamante è \acr{suid} o \acr{sgid}, vedi
+ sez.~\ref{sec:file_special_perm}),
+\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}),
+\item il valore della costante \const{P\_tmpdir},
+\item la directory \file{/tmp}.
+\end{itemize*}
+
+In ogni caso, anche se con queste funzioni la generazione del nome è casuale,
+ed è molto difficile ottenere un nome duplicato, nulla assicura che un altro
+processo non possa avere creato, fra l'ottenimento del nome e l'apertura del
+file, un altro file o un collegamento simbolico con lo stesso nome. Per questo
+motivo quando si usa il nome ottenuto da una di queste funzioni occorre sempre
+assicurarsi che non si stia usando un collegamento simbolico e aprire il nuovo
+file in modalità di esclusione (cioè con l'opzione \const{O\_EXCL} per i file
+descriptor o con il flag ``\texttt{x}'' per gli \textit{stream}) che fa
+fallire l'apertura in caso il file sia già esistente. Essendo disponibili
+alternative migliori l'uso di queste funzioni è deprecato.
+
+Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
+POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
+maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{FILE *tmpfile(void)}
+\fdesc{Apre un file temporaneo in lettura/scrittura.}
+}
+{La funzione ritorna il puntatore allo \textit{stream} associato al file
+ temporaneo in caso di successo e \val{NULL} per un errore, nel qual caso
+ \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EEXIST}] non è stato possibile generare un nome univoco.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{EMFILE}, \errval{ENFILE},
+ \errval{ENOSPC}, \errval{EROFS} e \errval{EACCES} nel loro significato
+ generico.}
+\end{funcproto}
+
+
+La funzione restituisce direttamente uno \textit{stream} già aperto (in
+modalità \code{w+b}, si veda sez.~\ref{sec:file_fopen}) e pronto per l'uso,
+che viene automaticamente cancellato alla sua chiusura o all'uscita dal
+programma. Lo standard non specifica in quale directory verrà aperto il file,
+ma la \acr{glibc} prima tenta con \const{P\_tmpdir} e poi con
+\file{/tmp}. Questa funzione è rientrante e non soffre di problemi di
+\textit{race condition}.
+
+Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
+caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
+modificano una stringa di input che serve da modello e che deve essere
+conclusa da 6 caratteri ``\texttt{X}'' che verranno sostituiti da un codice
+unico. La prima delle due è analoga a \func{tmpnam} e genera soltanto un nome
+casuale, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stlib.h}
+\fdecl{char *mktemp(char *template)}
+\fdesc{Genera un nome univoco per un file temporaneo.}
+}
+{La funzione ritorna il puntatore a \param{template} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
+ \end{errlist}}
+\end{funcproto}
+
+La funzione genera un nome univoco sostituendo le \code{XXXXXX} finali di
+\param{template}; dato che \param{template} deve poter essere modificata dalla
+funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
+alle possibili \textit{race condition} date per \func{tmpnam} continuano a
+valere; inoltre in alcune vecchie implementazioni il valore usato per
+sostituire le \code{XXXXXX} viene formato con il \ids{PID} del processo più
+una lettera, il che mette a disposizione solo 26 possibilità diverse per il
+nome del file, e rende il nome temporaneo facile da indovinare. Per tutti
+questi motivi la funzione è deprecata e non dovrebbe mai essere usata.
+
+La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
+\func{tmpfile}, ma restituisce un file descriptor invece di un nome; il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{stlib.h}
+\fdecl{int mkstemp(char *template)}
+\fdesc{Apre un file temporaneo.}
+}
+
+{La funzione ritorna il file descriptor in caso di successo e $-1$ per un
+ errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EEXIST}] non è riuscita a creare un file temporaneo, il
+ contenuto di \param{template} è indefinito.
+ \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
+ \end{errlist}}
+\end{funcproto}
+
+Come per \func{mktemp} anche in questo caso \param{template} non può essere
+una stringa costante. La funzione apre un file in lettura/scrittura con la
+funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda
+sez.~\ref{sec:file_open_close}), in questo modo al ritorno della funzione si
+ha la certezza di essere stati i creatori del file, i cui permessi (si veda
+sez.~\ref{sec:file_perm_overview}) sono impostati al valore \code{0600}
+(lettura e scrittura solo per il proprietario).\footnote{questo è vero a
+ partire dalla \acr{glibc} 2.0.7, le versioni precedenti della \acr{glibc} e
+ le vecchie \acr{libc5} e \acr{libc4} usavano il valore \code{0666} che
+ permetteva a chiunque di leggere e scrivere i contenuti del file.} Di
+questa funzione esiste una variante \funcd{mkostemp}, introdotta
+specificamente dalla \acr{glibc},\footnote{la funzione è stata introdotta
+ nella versione 2.7 delle librerie e richiede che sia definita la macro
+ \macro{\_GNU\_SOURCE}.} il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{stlib.h}
+\fdecl{int mkostemp(char *template, int flags)}
+\fdesc{Apre un file temporaneo.}
+}
+{La funzione ritorna un file descriptor in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà gli stessi valori di
+ \func{mkstemp}.}
+\end{funcproto}
+\noindent la cui sola differenza è la presenza dell'ulteriore argomento
+\var{flags} che consente di specificare alcuni ulteriori flag (come
+\const{O\_APPEND}, \const{O\_CLOEXEC}, \const{O\_SYNC}, il cui significato
+vedremo in sez.~\ref{sec:file_open_close}) da passare ad \func{open}
+nell'apertura del file.\footnote{si tenga presente che \func{mkostemp}
+ utilizza già \const{O\_CREAT}, \const{O\_EXCL} e \const{O\_RDWR}, che non è
+ il caso di riindicare, dato che ciò potrebbe portare ad errori in altri
+ sistemi operativi.}
+
+Di queste due funzioni sono state poi introdotte, a partire dalla \acr{glibc}
+2.11 due varianti, \funcd{mkstemps} e \funcd{mkostemps}, che consentono di
+indicare anche un suffisso, i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{stlib.h}
+\fdecl{int mkstemps(char *template, int suffixlen)}
+\fdesc{Apre un file temporaneo.}
+\fdecl{int mkostemps(char *template, int suffixlen, int flags)}
+\fdesc{Apre un file temporaneo.}
+}
+
+{Le funzioni hanno gli stessi valori di ritorno e gli stessi errori di
+ \func{mkstemp} con lo stesso significato, tranne \errval{EINVAL} che viene
+ restituito se \param{template} non è di lunghezza pari ad almeno
+ $6+$\param{suffixlen} ed i 6 caratteri prima del suffisso non sono
+ \code{XXXXXX}.}
+\end{funcproto}
+
+Le due funzioni, un'estensione non standard fornita dalla \acr{glibc}, sono
+identiche a \funcd{mkstemp} e \funcd{mkostemp}, ma consentono di avere un nome
+del file nella forma \texttt{prefissoXXXXXXsuffisso} dove la lunghezza del
+suffisso deve essere indicata con \param{suffixlen}.
+
+Infine con OpenBSD è stata introdotta un'altra funzione simile alle
+precedenti, \funcd{mkdtemp}, che crea invece una directory
+temporanea;\footnote{la funzione è stata introdotta nella \acr{glibc} a
+ partire dalla versione 2.1.91 ed inserita nello standard POSIX.1-2008.} il
+suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stlib.h}
+\fdecl{char *mkdtemp(char *template)}
+\fdesc{Crea una directory temporanea.}
+}
+{La funzione ritorna il puntatore al nome della directory in caso di successo
+ e \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno dei
+ valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
+ \end{errlist}
+ più gli altri eventuali codici di errore di \func{mkdir}.}
+\end{funcproto}
+
+La funzione crea una directory temporanea il cui nome è ottenuto sostituendo
+le \code{XXXXXX} finali di \param{template} con permessi \code{0700} (si veda
+sez.~\ref{sec:file_perm_overview} per i dettagli). Dato che la creazione della
+directory è sempre atomica i precedenti problemi di \textit{race condition}
+non si pongono.
+
+
+\section{La manipolazione delle caratteristiche dei file}
+\label{sec:file_infos}
+
+Come spiegato in sez.~\ref{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'\textit{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'\textit{inode}; esamineremo poi le varie funzioni usate per manipolare
+tutte queste informazioni, eccetto quelle che riguardano la gestione del
+controllo di accesso, trattate in sez.~\ref{sec:file_access_control}.
+
+
+\subsection{La lettura delle caratteristiche dei file}