+\const{AT\_REMOVEDIR}, essa si comporterà come \func{rmdir}, in tal caso
+\param{pathname} deve essere una directory, che sarà rimossa qualora risulti
+vuota. Non essendo in questo caso prevista la possibilità di usare altri
+valori (la funzione non segue comunque i collegamenti simbolici e
+\const{AT\_EMPTY\_PATH} non è supportato) anche se \param{flags} è una
+maschera binaria, essendo \const{AT\_REMOVEDIR} l'unico flag disponibile per
+questa funzione, lo si può assegnare direttamente.
+
+Un'altra funzione di sistema che usa l'argomento \param{flags} è
+\func{utimensat}, che però non è una corrispondente esatta delle funzioni
+classiche \func{utimes} e \func{lutimes}, in quanto ha una maggiore precisione
+nella indicazione dei tempi dei file, per i quali, come per \func{futimens},
+si devono usare strutture \struct{timespec} che consentono una precisione fino
+al nanosecondo; la funzione è stata introdotta con il kernel
+2.6.22,\footnote{in precedenza, a partire dal kernel 2.6.16, era stata
+ introdotta una \textit{system call} \funcm{futimesat} seguendo una bozza
+ della revisione dello standard poi modificata; questa funzione, sostituita
+ da \func{utimensat}, è stata dichiarata obsoleta, non è supportata da
+ nessuno standard e non deve essere più utilizzata: pertanto non ne
+ parleremo.} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fhead{sys/stat.h}
+\fdecl{int utimensat(int dirfd, const char *pathname, const struct
+ timespec times[2],\\
+\phantom{int utimensat(}int flags)}
+\fdesc{Cambia i tempi di un file.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà i valori di \func{utimes}, \func{lutimes} e
+ \func{futimens} con lo stesso significato ed inoltre:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{dirfd} non è \const{AT\_FDCWD} o un file
+ descriptor valido.
+ \item[\errcode{EFAULT}] \param{dirfd} è \const{AT\_FDCWD} ma
+ \param{pathname} è \var{NULL} o non è un puntatore valido.
+ \item[\errcode{EINVAL}] si usato un valore non valido per \param{flags},
+ oppure \param{pathname} è \var{NULL}, \param{dirfd} non è
+ \const{AT\_FDCWD} e \param{flags} contiene \const{AT\_SYMLINK\_NOFOLLOW}.
+ \item[\errcode{ESRCH}] non c'è il permesso di attraversamento per una delle
+ componenti di \param{pathname}.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione imposta i tempi dei file utilizzando i valori passati nel vettore
+di strutture \struct{timespec} ed ha in questo lo stesso comportamento di
+\func{futimens}, vista in sez.~\ref{sec:file_file_times}, ma al contrario di
+questa può essere applicata anche direttamente ad un file come \func{utimes};
+l'unico valore consentito per \param{flags} è \const{AT\_SYMLINK\_NOFOLLOW}
+che indica alla funzione di non dereferenziare i collegamenti simbolici, cosa
+che le permette di riprodurre anche le funzionalità di \func{lutimes} (con una
+precisione dei tempi maggiore).
+
+Su Linux solo \func{utimensat} è una \textit{system call} mentre
+\func{futimens} è una funzione di libreria, infatti \func{utimensat} ha un
+comportamento speciale se \param{pathname} è \var{NULL}, in tal caso
+\param{dirfd} viene considerato un file descriptor ordinario e il cambiamento
+del tempo viene applicato al file sottostante, qualunque esso sia. Viene cioè
+sempre usato il comportamento che per altre funzioni deve essere attivato con
+\const{AT\_EMPTY\_PATH} (che non è previsto per questa funzione) per cui
+\code{futimens(fd, times}) è del tutto equivalente a \code{utimensat(fd, NULL,
+ times, 0)}. Si tenga presente che nella \acr{glibc} questo comportamento è
+disabilitato, e la funzione, seguendo lo standard POSIX, ritorna un errore di
+\errval{EINVAL} se invocata in questo modo.
+
+Come corrispondente di \func{stat}, \func{fstat} e \func{lstat} si può
+utilizzare invece la funzione di sistema \funcd{fstatat}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fhead{sys/stat.h}
+\fdecl{int fstatat(int dirfd, const char *pathname, struct stat *statbuf, int
+ flags)}
+\fdesc{Legge le informazioni di un file.}
+}
+
+{La funzione ritorna gli stessi valori e gli stessi codici di errore di
+ \func{stat}, \func{fstat}, o \func{lstat} a seconda del valore di
+ \param{flags}, ed in più:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+ \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione ha lo stesso comportamento delle sue equivalenti classiche, l'uso
+di \param{flags} consente di farla comportare come \func{lstat} se si usa
+\const{AT\_SYMLINK\_NOFOLLOW}, o come \func{fstat} se si usa con
+\const{AT\_EMPTY\_PATH} e si passa il file descriptor in \param{dirfd}. Viene
+però supportato l'ulteriore valore \const{AT\_NO\_AUTOMOUNT} che qualora
+\param{pathname} faccia riferimento ad una directory marcata per
+l'\textit{automount} ne evita il montaggio automatico.
+
+Ancora diverso è il caso di \funcd{linkat} anche se in questo caso l'utilizzo
+continua ad essere attinente al comportamento con i collegamenti simbolici, il
+suo prototipo è:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int linkat(int olddirfd, const char *oldpath, int newdirfd, \\
+\phantom{int linkat(}const char *newpath, int flags)}
+\fdesc{Crea un nuovo collegamento diretto (\textit{hard link}).}
+}
+
+{La funzione ritorna gli stessi valori e gli stessi codici di errore di
+ \func{link}, ed in più:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{olddirfd} o \param{newdirfd} non sono un file
+ descriptor valido.
+ \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
+ \item[\errcode{ENOENT}] \param{oldpath} o \param{newpath} è un
+ \textit{pathname} relativo, ma la corrispondente directory di partenza
+ (\param{olddirfd} o \param{newdirfd}) è stata cancellata, oppure si è
+ cercato di creare un \textit{link} da un file descriptor aperto con
+ \const{O\_TMPFILE} e \const{O\_EXCL}, oppure si è usato
+ \const{AT\_EMPTY\_PATH} senza privilegi amministrativi.
+ \item[\errcode{ENOTDIR}] \param{oldpath} e \param{newpath} sono
+ \textit{pathname} relativi, ma \param{olddirfd} o \param{newdirfd} fa
+ riferimento ad un file.
+ \item[\errcode{EPERM}] si è usato \const{AT\_EMPTY\_PATH} con
+ \param{oldpath} vuoto e \param{olddirfd} che fa riferimento ad una
+ directory.
+ \end{errlist}
+}
+\end{funcproto}
+
+Anche in questo caso la funzione svolge lo stesso compito della
+corrispondente classica \func{link}, ma dovendo specificare due
+\textit{pathname} (sorgente e destinazione) aggiunge a ciascuno di essi un
+argomento (rispettivamente \param{olddirfd} e \param{newdirfd}) per poter
+indicare entrambi come relativi a due directory aperte in precedenza.
+
+In questo caso, dato che su Linux il comportamento di \func{link} è quello di
+non seguire mai i collegamenti simbolici, \const{AT\_SYMLINK\_NOFOLLOW} non
+viene utilizzato. A partire dal kernel 2.6.18 è stato aggiunto a questa
+funzione la possibilità di usare il valore \const{AT\_SYMLINK\_FOLLOW} per
+l'argomento \param{flags},\footnote{nei kernel precedenti, dall'introduzione
+ nel 2.6.16, l'argomento \param{flags} era presente, ma senza alcun valore
+ valido, e doveva essere passato sempre con valore nullo.} che richiede di
+dereferenziare un eventuale collegamento simbolico creando un \textit{hard
+ link} al file puntato da quest'ultimo.
+
+Inoltre a partire dal kernel 3.11 si può usare \const{AT\_EMPTY\_PATH} con lo
+stesso significato già visto in precedenza applicato ad \param{olddirfd}, si
+può cioè creare un nuovo \textit{hard link} al file associato al file
+descriptor \param{olddirfd}, passando un valore nullo per
+\param{oldpath}. Questa operazione però è privilegiata e richiede i privilegi
+di amministratore (la \textit{capability} \const{CAP\_DAC\_READ\_SEARCH}),
+infatti in questo modo la funzione si comporta come una ipotetica
+\texttt{flink}, una \textit{system call} di cui è stato spesso chiesta la
+creazione, che permetterebbe di associare direttamente un nome ad un file
+descriptor, ma che non è mai stata realizzata per problemi di sicurezza.
+
+Il problema infatti è che le verifiche di accesso sono fatte quando il file
+viene aperto e non attengono solo ai permessi del file stesso, ma anche a
+quelli delle directory del suo \textit{pathname}; se una volta aperto venisse
+collegato in un altra directory eventuali restrizioni imposte sulle directory
+del suo \textit{pathname} andrebbero perse. Inoltre sarebbe possibile accedere
+al file sottostante anche in scrittura per un file descriptor che è stato
+fornito come aperto in sola lettura, o con accesso libero per un file
+descriptor fornito aperto in \textit{append}. Infine e la funzione
+consentirebbe rendere accessibile all'interno di un \textit{choot} (vedi
+sez.~\ref{sec:file_chroot}) un qualunque file sia stato aperto fuori dallo
+stesso prima di entrarvi.
+
+% NOTE per la discussione sui problemi di sicurezza relativi a questa
+% funzionalità vedi http://lwn.net/Articles/562488/
+
+Per questo motivo l'uso di \const{AT\_EMPTY\_PATH} richiede comunque privilegi
+amministrativi, anche se, quando è disponibile il filesystem \texttt{/proc}, è
+possibile usare \func{linkat} per creare un file da un qualunque file
+descriptor un processo abbia aperto, usandola con un codice analogo al
+seguente:\footnote{non esiste al momento, se si sta usando il filesystem
+ \textit{proc}, una modalità per evitare i rischi illustrati in precedenza.}
+\includecodesnip{listati/procfd_linkat.c}
+e questa modalità è anche quella con cui è possibile assegnare in un secondo
+tempo il nome ad un file anonimo creato usando \func{open} con
+\const{O\_TMPFILE}; ma si deve tenere presente che per questi file la funzione
+ha un comportamento particolare.
+
+In generale infatti quando il file sorgente di \func{linkat} ha un numero di
+collegamenti nulli (cosa che avviene ad esempio quando si apre un file
+temporaneo e lo si cancella subito dopo oppure quando viene cancellato un file
+aperto in precedenza) la funzione non consente di ricollegarlo ad un altro
+file riassegnandogli un nuovo nome e fallisce sempre con un errore di
+\errval{ENOENT} qualunque siano i permessi del processo, e che si usi questo
+approccio o \const{AT\_EMPTY\_PATH}. Ma questo non avviene se il file
+descriptor è stato ottenuto con \const{O\_TMPFILE}, in tal caso la funzione ha
+successo, a meno che non si sia usato nell'apertura anche \const{O\_EXCL} per
+impedire questo comportamento, e continuare ad ottenere \errval{ENOENT}.
+
+In fig.~\ref{fig:initfile} si è riportato il codice della funzione
+\func{InitFile}, che consente di creare in maniera sicura il contenuto
+iniziale di un file utilizzando \const{O\_TMPFILE} e \func{linkat}, come
+accennato a pag.~\pageref{open_o_tmpfile_flag}. La funzione richiede di
+indicare il file da creare usando la sintassi delle \textit{at-functions},
+specificando la directory in cui crearlo con il corrispondente file descriptor
+passato nell'argomento \texttt{dirfd} ed il pathname relativo ed essa passato
+l'argomento \texttt{file}; il contenuto iniziale del file deve essere fornito
+nel buffer \texttt{buf} di lunghezza \texttt{size}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/InitFile.c}
+ \end{minipage}
+ \caption{Esempio di codice per creare in maniera sicura il contenuto
+ iniziale di un file.}
+ \label{fig:initfile}
+\end{figure}
+
+La funzione come primo passo (\texttt{\small 6--10}) ottiene un file
+descriptor accessibile in lettura/scrittura invocando \func{openat} con il
+flag \const{O\_TMPFILE} per ottenere un file anonimo, facendo riferimento a
+quella che sarà la directory di destinazione in cui poi verrà collegato lo
+stesso passata dal chiamante in \texttt{dirfd}, usando ``\texttt{.}'' come
+\textit{pathname} relativo. Si noti come nella chiamata si impostino anche
+(per semplicità si è usato un valore fisso) i valori iniziali dei permessi del
+file (lettura e scrittura solo per il proprietario), e come dopo la chiamata
+si controlli la presenza di un eventuale errore, ritornandolo con un messaggio
+qualora avvenga.
+
+Il secondo passo (\texttt{\small 11--15}) è quello di chiamare la funzione
+\func{FullWrite} (che tratteremo in dettaglio in sez.~\ref{sec:sock_io_behav})
+per eseguire la scrittura del contenuto del buffer \texttt{buf} sul file
+anonimo ottenuto con \func{openat}; in sostanza la funzione scrive tutto il
+contenuto del buffer, iterando le scritture qualora non sia possibile eseguire
+tutto con una singola \func{write}, cosa che comunque per i file su disco in
+genere non avviene mai.
+
+Una volta completata con successo la scrittura l'ultimo passo (\texttt{\small
+ 17--23}) è collegare il file anonimo con \func{linkat}, per questo però
+occorre utilizzare il \textit{pathname} ad esso associato sotto
+\texttt{/proc}, che viene ottenuto (\texttt{\small 16}) con una
+\func{snprintf} (vedi sez.~\ref{sec:file_formatted_io}) usando file descriptor
+restituito da \func{openat}. Con questo \textit{pathname} si può procedere
+(\texttt{\small 17}) a chiamare \func{linkat} per eseguire il collegamento, in
+cui occorre usare il flag \const{AT\_SYMLINK\_NOFOLLOW} come nell'esempio
+precedente.
+
+Altre due funzioni che utilizzano due \textit{pathname} (e due file
+descriptor) sono \funcd{renameat} e \funcd{renameat2}, corrispondenti alla
+classica \func{rename}; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int renameat(int olddirfd, const char *oldpath, int newdirfd, const
+ char *newpath)}
+\fdecl{int renameat2(int olddirfd, const char *oldpath, int newdirfd, \\
+\phantom{int renameat2(}const char *newpath, int flags)}
+\fdesc{Rinomina o sposta un file o una directory.}
+}
+
+{La funzioni ritornano gli stessi valori e gli stessi codici di errore di
+ \func{rename}, ed in più per entrambe:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{olddirfd} o \param{newdirfd} non sono un file
+ descriptor valido.
+ \item[\errcode{ENOTDIR}] \param{oldpath} e \param{newpath} sono
+ \textit{pathname} relativi, ma i corrispondenti \param{oldirfd} o
+ \param{newdirfd} fan riferimento ad un file e non a una directory.
+ \end{errlist}
+ e per \func{renameat2} anche:
+ \begin{errlist}
+ \item[\errcode{EEXIST}] si è richiesto \macro{RENAME\_NOREPLACE} ma
+ \param{newpath} esiste già.
+ \item[\errcode{EINVAL}] Si è usato un flag non valido in \param{flags}, o si
+ sono usati insieme a \macro{RENAME\_EXCHANGE} o \macro{RENAME\_NOREPLACE}
+ o \macro{RENAME\_WHITEOUT}, o non c'è il supporto nel filesystem per una
+ delle operazioni richieste in \param{flags}.
+ \item[\errcode{ENOENT}] si è richiesto \macro{RENAME\_EXCHANGE} e
+ \param{newpath} non esiste.
+ \item[\errcode{EPERM}] si è richiesto \macro{RENAME\_WHITEOUT} ma il
+ chiamante non ha i privilegi di amministratore.
+ \end{errlist}
+}
+\end{funcproto}
+
+In realtà la corrispondente di \func{rename}, prevista dallo standard
+POSIX.1-2008 e disponibile dal kernel 2.6.16 come le altre
+\textit{at-functions}, sarebbe soltanto \func{renameat}, su Linux però, a
+partire dal kernel dal 3.15, questa è stata realizzata in termini della nuova
+funzione di sistema \func{renameat2} che prevede l'uso dell'argomento
+aggiuntivo \param{flags}; in questo caso \func{renameat} è totalmente
+equivalente all'utilizzo di \func{renamat2} con un valore nullo per
+\param{flags}.
+
+L'uso di \func{renameat} è identico a quello di \func{rename}, con la sintassi
+delle \textit{at-functions} applicabile ad entrambi i \textit{pathname} passati
+come argomenti alla funzione. Con \func{renameat2} l'introduzione
+dell'argomento \func{flags} (i cui valori possibili sono riportati in
+tab.~\ref{tab:renameat2_flag_values}) ha permesso di aggiungere alcune
+funzionalità specifiche di Linux non previste al momento da nessuno standard
+(la funzione è disponibile nelle \acr{glibc} a partire dalla versione 2.28).