+\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).
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{RENAME\_EXCHANGE} & richiede uno scambio di nomi fra
+ \param{oldpath} e \param{newpath}, non è
+ usabile con \const{RENAME\_NOREPLACE}.\\
+ \const{RENAME\_NOREPLACE}& non sovrascrive \param{newpath} se questo
+ esiste dando un errore.\\
+ \const{RENAME\_WHITEOUT} & crea un oggetto di \textit{whiteout}
+ contestualmente al cambio di nome
+ (disponibile a partire dal kernel 3.18).\\
+ \hline
+ \end{tabular}
+ \caption{I valori specifici dei bit dell'argomento \param{flags} per l'uso
+ con \func{renameat2}.}
+ \label{tab:renameat2_flag_values}
+\end{table}
+
+L'uso dell'argomento \param{flags} in questo caso non attiene alle
+funzionalità relative alla \textit{at-functions}, ma consente di estendere le
+funzionalità di \func{rename}. In particolare \func{renameat2} consente di
+eseguire uno scambio di nomi in maniera atomica usando il flag
+\constd{RENAME\_EXCHANGE}; se specificato la funzione rinomina in un colpo
+solo \param{oldpath} in \param{newpath} e \param{newpath} in
+\param{oldpath}. Usando questo flag, entrambi i \textit{pathname} passati come
+argomenti devono esistere, e non è possibile usare \const{RENAME\_NOREPLACE},
+non ci sono infine restrizioni sul tipo di file (regolare, directory, link
+simbolici, dispositivo) di cui si scambia il nome.
+
+Il flag \constd{RENAME\_NOREPLACE} consente di richiedere la generazione di un
+errore nei casi in cui \func{rename} avrebbe causato una sovrascrittura della
+destinazione, rendendo possibile evitare la stessa in maniera atomica; un
+controllo preventivo dell'esistenza del file infatti avrebbe aperto alla
+possibilità di una \textit{race condition} fra il momento del controllo e
+quella del cambio di nome.
+
+\itindbeg{overlay~filesytem}
+\itindbeg{union~filesytem}
+
+Infine il flag \constd{RENAME\_WHITEOUT}, introdotto con il kernel 3.18,
+richiede un approfondimento specifico, in quanto attiene all'uso della
+funzione con dei filesystem di tipo \textit{overlay}/\textit{union}, dato che
+il flag ha senso solo quando applicato a file che stanno su questo tipo di
+filesystem. Un \textit{overlay} o \textit{union filesystem} è un filesystem
+speciale strutturato in livelli, in cui si rende scrivibile un filesystem
+accessibile in sola lettura, \textsl{sovrapponendogli} un filesystem
+scrivibile su cui vanno tutte le modifiche. Un tale tipo di filesystem serve
+ad esempio a rendere scrivibili i dati processati quando si fa partire una
+distribuzione \textit{Live} basata su CD o DVD, ad esempio usando una
+chiavetta o uno spazio disco aggiuntivo.
+
+In questo caso quando si rinomina un file che sta nello strato in sola lettura
+questo viene copiato a destinazione sulla parte accessibile in scrittura, ma
+l'originale non può essere cancellato; per far si che esso non appaia più è
+possibile creare un oggetto speciale del filesystem, chiamato
+\textit{whiteout}, che serve a renderlo non più visibile. La funzione consente
+di creare questo oggetto, che in un filesystem ordinario verrebbe visto come
+un file di dispositivo con \textit{major minor} e \textit{minor number} nulli,
+in maniera atomica quando si rinomina un file. Dato che l'uso di
+\const{RENAME\_WHITEOUT} comporta in sostanza la creazione di un file di
+dispositivo, l'operazione è privilegiata (occorre la \textit{capability}
+\texttt{CAP\_MKNOD}), inoltre occorre anche il supporto nel filesystem usato
+come supporto per la scrittura. Infine l'operazione non è compatibile con
+\const{RENAME\_EXCHANGE}.
+
+\itindend{overlay~filesytem}
+\itindend{union~filesytem}
+
+Benché non rientri nelle \textit{at-functions} previste nello standard
+POSIX.1-2008, tratteremo qui anche la funzione di sistema \funcd{statx},
+introdotta con il kernel 4.11 e disponibile dalle versione 2.28 della
+\acr{glibc}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/stat.h}
+\fhead{unistd.h}
+\fhead{fcntl.h}
+\fdecl{int statx(int dirfd, const char *pathname, int flags, \\
+\phantom{int statx(}unsigned int mask, struct statx *statxbuf)}
+\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 o \param{mask}
+ ha un valore riservato.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione è una estensione specifica di Linux consente di leggere le
+informazioni di un file; ha la stessa sintassi di \func{fstatat} utilizzando
+con lo stesso significato gli argomenti \param{dirfd} e \param{pathname} ed i
+valori \const{AT\_EMPTY\_PATH}, \const{AT\_NO\_AUTOMOUNT} e
+\const{AT\_SYMLINK\_NOFOLLOW} per \param{flags}. Si può pertanto indicare il
+file di cui si vogliono ottenere i dati con un \textit{pathname} assoluto, con
+un \textit{pathname} relativo (sia alla directory corrente che a quella
+indicata da \param{dirfd}) o con un file descriptor ad esso associato.
+
+La funzione però consente di ottenere informazioni più dettagliate rispetto a
+quelle fornite dalle funzioni tradizionali come \func{stat} e \func{fstatat},
+ed è in grado di controllare le modalità con cui le ottiene nel caso un file
+sia posto su un filesystem remoto. Per questo, oltre ai tre valori
+precedenti, l'argomento \param{flags} consente anche gli ulteriori valori
+elencati in tab.~\ref{tab:statx_flags_const}, con il significato ivi
+illustrato.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{AT\_STATX\_SYNC\_AS\_STAT}& si comporta esattamente come
+ \func{stat}, in questo caso (il default
+ se non viene indicato niente) il
+ risultato dipende dal tipo di
+ filesystem.\\
+ \constd{AT\_STATX\_FORCE\_SYNC}& richiede che i valori degli attributi
+ richiesti siano, in caso di un filesystem
+ di rete, siano sincronizzati con il server
+ remoto, questo può forzare una scrittura
+ dei dati (in particolare i tempi del file)
+ verso lo stesso.\\
+ \constd{AT\_STATX\_DONT\_SYNC} & chiede di non sincronizzare nessun dato,
+ ritornando quanto presente nella cache,
+ questo significa che i dati potrebbero
+ essere non coerenti ed aggiornati, ma si
+ evita, in caso di filesystem di rete, la
+ necessità di contattare il server remoto.\\
+ \hline
+ \end{tabular}
+ \caption{Valori specifici di \func{statx} per l'argomento \param{flags}.}
+ \label{tab:statx_flags_const}
+\end{table}
+
+La funzione restituisce le informazioni relative al file richiesto nella
+struttura \struct{statx} puntata dall'argomento \param{statxbuf}. Inoltre
+data la quantità di informazioni che possono essere richieste, la funzione
+consente, con l'argomento \param{mask} di selezionare quelle volute, questa
+deve essere assegnata ad una maschera binaria dei valori illustrati in
+tab.~\ref{tab:statx_mask_const}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{STATX\_TYPE} & Tipo del file (\texttt{stx\_mode \& S\_IFMT}).\\
+ \constd{STATX\_MODE} & Permessi del file (\texttt{stx\_mode \&
+ \tild{}S\_IFMT}).\\
+ \constd{STATX\_NLINK} & Numero di collegamenti (\textit{hard link},
+ \texttt{stx\_nlink}).\\
+ \constd{STATX\_UID} & Proprietario del file (per \ids{UID},
+ \texttt{stx\_uid}).\\
+ \constd{STATX\_GID} & Gruppo proprietario del file (per \ids{GID},
+ \texttt{stx\_gid}).\\
+ \constd{STATX\_ATIME} & Tempo di ultimo accesso (\texttt{stx\_atime}).\\
+ \constd{STATX\_MTIME} & Tempo di ultima modifica (\texttt{stx\_mtime}).\\
+ \constd{STATX\_CTIME} & Tempo di ultimo cambiamento (\texttt{stx\_ctime}).\\
+ \constd{STATX\_INO} & Numero di \textit{inode} (\texttt{stx\_ino}).\\
+ \constd{STATX\_SIZE} & Dimensione del file (\texttt{stx\_size}).\\
+ \constd{STATX\_BLOCKS}& Numero di blocchi del file (\texttt{stx\_blocks}).\\
+ \constd{STATX\_BASIC\_STATS}& Tutte le informazioni precedenti.\\
+ \constd{STATX\_BTIME} & Tempo di creazione (\texttt{stx\_btime}).\\
+% \constd{}& .\\
+ \constd{STATX\_ALL} & Tutte le informazioni.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti per i valori dell'argomento \param{mask} di
+ \func{statx}.}
+ \label{tab:statx_mask_const}
+\end{table}
+
+Si tenga presente che il kernel non richiede che \param{mask} contenga solo i
+flag di tab.~\ref{tab:statx_mask_const}, valori ulteriori in genere vengono
+ignorati ma non si può comunque indicare un valore qualunque in quanto alcuni
+bit sono riservati per future estensioni.\footnote{in particolare il bit
+ \constd{STATX\_\_RESERVED} che se usato causa il fallimento della funzione
+ con un errore di \errval{EINVAL}.} Inoltre non è detto che tutte le
+informazioni richieste con \param{mask} siano disponibili, per questo il
+kernel restituisce in un opportuno campo della struttura \struct{statx},
+\var{stx\_mask}, quali sono i dati effettivamente restituiti, che possono in
+alcuni casi essere anche di più di quelli richiesti (se l'informazione
+aggiuntiva è ottenuta senza costi ulteriori) per cui è normale che questo
+valore possa essere diverso da quanto richiesto.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/statx.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{statx} per la lettura delle informazioni dei
+ file.}
+ \label{fig:file_statx_struct}
+\end{figure}
+
+Si è riportata in fig.~\ref{fig:file_statx_struct} la definizione della
+struttura \struct{statx} come presente in \headfile{sys/stat.h}; i campi
+\var{stx\_mode}, \var{stx\_nlink}, \var{stx\_uid}, \var{stx\_gid},
+\var{stx\_ino}, \var{stx\_size}, \var{stx\_blksize}, \var{stx\_blocks} sono
+identici agli analoghi (con prefisso \texttt{st\_}) dell'ordinaria struttura
+\struct{stat} illustrata in fig.~\ref{fig:file_stat_struct} e vale per essi
+quanto già detto in sez.~\ref{sec:file_stat} e seguenti.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/statx_timestamp.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{statx\_timestamp} per i tempi dei file con
+ \func{statx}. }
+ \label{fig:file_statx_timestamp_struct}
+\end{figure}
+
+Anche i campi \var{stx\_atime}, \var{stx\_mtime}, \var{stx\_ctime} mantengono
+questa analogia, ma esprimono i tempi di ultimo accesso, modifica e
+cambiamento con una precisione ed estensione maggiore grazie all'uso di una
+struttura dedicata \struct{statx\_timestamp} (riportata in
+fig.~\ref{fig:file_statx_timestamp_struct}) che consente di estendere i tempi
+dei file ad una granularità del nanosecondo e con un valore dello \textit{unix
+ time} (vedi sez.~\ref{sec:sys_unix_time}) a 64 bit, che non darà problemi di
+overflow per parecchio tempo (sicuramente ben oltre la durata di questa
+guida).
+
+Oltre ai precedenti, e a \val{stx\_mask} che abbiamo già visto e che indica
+quali delle informazioni richieste alla funzione sono state fornite,
+\func{statx} prevede una serie di informazioni aggiuntive fornite in
+altrettanti nuovi campi, illustrati nell'elenco seguente. È comunque previsto
+che in futuro \struct{statx} venga estesa per supportare ulteriori
+informazioni.
+
+\begin{basedescript}{\desclabelwidth{1.6cm}\desclabelstyle{\nextlinelabel}}
+\item[\var{stx\_btime}] In questo campo viene restituito il \textsl{tempo di
+ creazione} del file. Come detto in sez.~\ref{sec:file_file_times} questo
+ tempo normalmente non esiste in un sistema \textit{unix-like}, ma per
+ migliorare l'interoperabilità è stato aggiunto nelle versioni più recenti di
+ vari filesystem (come XFS, \acr{ext4}, ecc.) in modo che possa essere
+ utilizzato da servizi di condivisione dei file (è usato da \textsl{Samba},
+ ed è previsto nello standard di NFSv4).
+\item[\var{stx\_attributes\_mask}] in questo campo viene restituita una
+ maschera che indica quali sono i bit restituiti in \var{stx\_attributes}
+ effettivamente supportati per il file, e per poter utilizzare quest'ultimo
+ occorre sempre eseguire un AND aritmetico con \var{stx\_attributes\_mask} per
+ ottenere i valori validi.
+\item[\var{stx\_attributes}] in questo campo vengono restituiti gli eventuali
+ attributi addizionali posseduti dal file. Gran parte di questi sono quelli
+ impostati con i comandi \cmd{lsattr} e \cmd{chattr} ed abbiamo già incontrato
+ alcuni di essi in sez.~\ref{sec:file_perm_overview}. Gli attributi vengono
+ restituiti in forma di maschera binaria con i valori delle costanti elencate
+ in tab.~\ref{tab:statx_stx_attributes}, dove si trova anche la relativa
+ descrizione.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{STATX\_ATTR\_COMPRESSED}& Il file è compresso automaticamente dal
+ filesystem (quindi può richiedere un
+ maggior uso di risorse in caso di
+ accesso).\\
+ \constd{STATX\_ATTR\_IMMUTABLE} & Il file è marcato come
+ \textit{immutable} e non può essere
+ modificato in nessun modo (vedi
+ sez.~\ref{sec:file_perm_overview}).\\
+ \constd{STATX\_ATTR\_APPEND} & Il file è marcato come
+ \textit{append-only} e può essere
+ soltanto esteso in \textit{append} (vedi
+ sez.~\ref{sec:file_perm_overview}).\\
+ \constd{STATX\_ATTR\_NODUMP} & Il file è marcato per essere escluso da
+ eventuali backup a livello di filesystem
+ come quelli eseguiti con il comando
+ \cmd{dump}.\\
+ \constd{STATX\_ATTR\_ENCRYPTED} & Il file è cifrato sul filesystem ed è
+ necessaria una chiave di accesso per
+ decifrarne il contenuto.\\
+ \constd{STATX\_ATTR\_AUTOMOUNT} & Il file, in questo caso in genere una
+ directory, è marcata come punto di
+ innesco per un \textit{automount}.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti degli attributi addizionali restituiti in
+ \var{stx\_attributes}.}
+ \label{tab:statx_stx_attributes}
+\end{table}
+
+\item[\var{stx\_rdev\_major}, \var{stx\_rdev\_minor}] in questi campi vengono
+ restituiti rispettivamente \textit{major number} e \textit{minor number} del
+ file quando questo è un file di dispositivo (fanno le veci del campo
+ \var{st\_rdev} di \struct{stat}).
+
+\item[\var{stx\_dev\_major}, \var{stx\_dev\_minor}] in questi campi vengono
+ restituiti \textit{major number} e \textit{minor number} del dispositivo su
+ cui risiede il file (fanno le veci del campo \var{st\_dev} di \struct{stat}).
+\end{basedescript}
+
+Di questi campi \var{stx\_mode}, \var{stx\_nlink}, \var{stx\_uid},
+\var{stx\_gid}, \var{stx\_ino}, \var{stx\_size} e \var{stx\_blocks} e quelli
+relativi ai tempi ordinari dei file vengono sempre restituiti, ed il relativo
+valore in \struct{statx} sovrascritto, indipendentemente dal fatto che siano
+stati richiesti o no, con \var{stx\_mask} che indicherà quali sono quelli che
+hanno valori effettivamente validi.
+
+Se un filesystem ha dei campi che non esistono o hanno valori senza
+corrispondenza in un sistema unix-like, questi potranno essere restituiti con
+valori fittizi ricostruiti, ad esempio usando \ids{UID} e \ids{GID} impostati
+in fase di montaggio per un filesystem che non supporta gli utenti; in questi
+casi il relativo bit in \var{stx\_mask} sarà comunque cancellato. In caso di
+cambiamenti al file eseguiti in concorrenza a \func{statx} è possibile che
+campi diversi possano avere informazioni ottenute in momenti diversi, con
+valori precedenti o posteriori il cambiamento. Inoltre, se non richiesti
+esplicitamente, alcuni campi possono avere valori approssimati, ad esempio in
+caso di NFS, questi non vengono mai aggiornati dallo stato sul server remoto.
+
+Il campo \var{stx\_btime} viene restituito solo se richiesto, e si otterrà un
+valore nullo (ed il relativo bit in \var{stx\_mask} cancellato) se questo non
+esiste. Lo stesso vale nel caso si siano richiesti \var{stx\_rdev\_major} o
+\var{stx\_rdev\_minor} ed il file non è un file di dispositivo. I campi
+\var{stx\_dev\_major}, \var{stx\_dev\_minor} e \var{stx\_blksize} attengono
+ad informazioni locali, e sono sempre disponibili in maniera diretta.
+
+% NOTE: per statx https://lwn.net/Articles/707602/ e
+% https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f)
+
+Infine trattiamo qui altre due funzioni, \func{fexecve} e \func{execveat}, che
+non attengono che in maniera indiretta all'uso dei file, ma sono comunque
+legate all'interfaccia delle \textit{at-functions}. In realtà la sola
+effettivamente collegata all'interfaccia delle \textit{at-functions} è la
+funzione di sistema \func{execveat}, introdotta con il kernel 3.19, e per la
+quale non è disponibile ancora un'interfaccia diretta nella \acr{glibc} che
+però la usa (quando disponibile) per realizzare \func{fexecve}.
+
+L'introduzione di queste funzioni nasce dall'esigenza di verificare i
+contenuti di un file eseguibile prima di eseguirlo. Fare il controllo (aprendo
+il file e verificandone il contenuto) e poi eseguirlo con \func{execve} è
+suscettibile alla possibilità che fra il controllo e l'esecuzione il nome del
+file o di una directory sovrastante venga cambiato.
+
+Per mitigare il problema nello standard POSIX.1-2008 è stata introdotta la
+funzione \funcd{fexecve} che consente di eseguire un programma usando un file
+descriptor al posto di un \textit{pathname}; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int fexecve(int fd, char *const argv[], char *const envp[])}
+\fdesc{Esegue un programma da un file descriptor.}
+}
+
+{La funzione non ritorna in caso di successo e ritorna $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{fd} non è un file descriptor, o \param{argv}
+ o \param{envp} sono \val{NULL}.
+ \item[\errcode{ENOSYS}] il filesystem \file{proc} non è disponibile (prima
+ del kernel 3.19).
+ \end{errlist}
+ oltre a tutti gli errori già visti per \func{execve}.}
+\end{funcproto}
+
+La funzione esegue il programma contenuto nel file (su cui il chiamante deve
+avere il permesso di esecuzione) corrispondente a \param{fd}; questo deve
+essere stato ottenuto aprendo il relativo eseguibile in sola lettura o con
+\const{O\_PATH}. Questa funzione fino al kernel 3.19 veniva realizzata nella
+\acr{glibc} usando il filesystem \file{/proc} per ottenere da \param{fd} il
+file corrispondente in \file{/proc/self/fd/}, in maniera analoga a quanto
+visto per l'esempio di fig.~\ref{fig:initfile}.
+
+La funzione di sistema \funcd{execveat} è stata introdotta proprio per rendere
+più sicura l'esecuzione ed evitare la necessità di avere disponibile
+\file{/proc} per poter usare \func{fexecve}, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int execveat(int dirfd, const char *pathname, char *const argv[], \\
+\phantom{int execveat(}char *const envp[], int flags)}
+\fdesc{Esegue un programma relativo ad una directory.}
+}
+
+{La funzione non ritorna in caso di successo e ritorna $-1$ per un errore, nel
+ qual caso \var{errno} assumerà, inoltre tutti gli errori già visti per
+ \func{execve}, uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor valido.
+ \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
+ \item[\errcode{ELOOP}] si è usato \const{AT\_SYMLINK\_NOFOLLOW} in
+ \param{flags} ma il file indicato è un link simbolico.
+ \item[\errcode{ENOENT}] il programma di cui si è richiesta l'esecuzione è
+ uno script, ma \func{dirfd} è aperto con il flag di
+ \textit{close-on-exec} e pertanto il programma non sarebbe accessibile
+ all'interprete.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione segue la sintassi delle \textit{at-functions} per indicare il file
+da eseguire, e per il resto si comporta esattamente con come \func{execve} (le
+cui caratteristiche sono già state illustrate in
+sez.~\ref{sec:proc_exec}). Diventa così possibile indicare il programma da
+eseguire sia con un \textit{pathname} assoluto che relativo (usando
+\const{AT\_FDCWD} come \param{dirfd}), oppure con un \textit{pathname}
+relativo alla directory indicata da \param{dirfd}. In quest'ultima forma l'uso
+della funzione consente estendere i vantaggi delle \textit{at-functions} anche
+al caso dell'esecuzione di un programma.
+
+Inoltre usando, per \param{flags} il valore \const{AT\_EMPTY\_PATH}, si può
+indicare direttamente il file da eseguire aprendolo e passandone il file
+descriptor nell'argomento \param{dirfd}, ottenendo il comportamento di
+\func{fexecve}; quest'ultima infatti è sostanzialmente equivalente
+all'esecuzione di:
+\includecodesnip{listati/fexecve.c}
+l'unico altro valore utilizzabile per \param{flags} è
+\const{AT\_SYMLINK\_NOFOLLOW}, che fa fallire la funzione con un errore di
+\errval{ELOOP} se il file indicato è un link simbolico.
+
+Quando si usano \func{execveat} o \func{fexecve} per eseguire un programma
+attraverso un file descriptor è naturale impostare sullo stesso il flag di
+\textit{close-on-exec} in modo che questo venga automaticamente chiuso
+all'esecuzione. Questo evita di lasciare aperto inutilmente un file descriptor
+(un programma in genere non ha bisogno di avere un file aperto su se stesso),
+ma soprattutto evita problemi in caso di un eventuale uso ricorsivo di queste
+funzioni, in tal caso infatti, restando aperto ad ogni iterazione un ulteriore
+file descriptor, si potrebbe arrivare all'esaurimento degli stessi.
+
+Tutto questo però non è vero quando si vuole eseguire uno script; in tal caso
+infatti (si ricordi quanto detto a questo riguardo in
+sez.~\ref{sec:proc_exec}) il programma che viene effettivamente messo in
+esecuzione è l'interprete indicato nella riga iniziale dello script, che poi
+legge ed interpreta il codice da eseguire dallo script stesso. Ma se lancia lo
+script usando un file descriptor su cui è attivo il flag di
+\textit{close-on-exec}, questo sarà già chiuso quando l'interprete viene posto
+in esecuzione, rendendo impossibile la lettura del programma da
+interpretare.
+
+Per questo motivo, quando ci si trova in questa situazione, \func{execveat} (e
+quindi anche \func{fexecve}) eseguono un controllo preventivo e falliscono con
+un errore di \errval{ENOENT}. Pertanto se si vuole eseguire uno script
+passandone il file descriptor l'unica possibilità è non attivare il flag di
+\textit{close-on-exec}, esponendosi però al rischio di incorrere nei problemi
+accennati in precedenza.
+
+% TODO: manca prototipo e motivazione di fexecve, da trattare qui in quanto
+% inserita nello stesso standard e da usare con openat, vedi
+% http://pubs.opengroup.org/onlinepubs/9699939699/toc.pdf
+
+% TODO manca prototipo di execveat, introdotta nel 3.19, vedi
+% https://lwn.net/Articles/626150/ cerca anche fexecve
+
+
+% TODO: trattare i nuovi AT_flags quando e se arriveranno, vedi
+% https://lwn.net/Articles/767547/
+
+\itindend{at-functions}
+
+
+\subsection{Le operazioni di controllo}
+\label{sec:file_fcntl_ioctl}
+
+Oltre alle operazioni base esaminate in sez.~\ref{sec:file_unix_interface}
+esistono tutta una serie di operazioni ausiliarie che è possibile eseguire su
+un file descriptor, che non riguardano la normale lettura e scrittura di dati,
+ma la gestione sia delle loro proprietà, che di tutta una serie di ulteriori
+funzionalità che il kernel può mettere a disposizione.
+
+% TODO: trattare qui i file seal
+
+Per le operazioni di manipolazione e di controllo delle varie proprietà e
+caratteristiche di un file descriptor, viene usata la funzione di sistema
+\funcd{fcntl},\footnote{ad esempio si gestiscono con questa funzione varie
+ modalità di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_operation}) e
+ il \textit{file locking} (vedi sez.~\ref{sec:file_locking}).} il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{fcntl.h}
+\fdecl{int fcntl(int fd, int cmd)}
+\fdecl{int fcntl(int fd, int cmd, long arg)}
+\fdecl{int fcntl(int fd, int cmd, struct flock * lock)}
+\fdecl{int fcntl(int fd, int cmd, struct f\_owner\_ex * owner)}
+\fdesc{Esegue una operazione di controllo sul file.}
+}
+
+{La funzione ha valori di ritorno diversi a seconda dell'operazione richiesta
+ in caso di successo mentre ritorna sempre $-1$ per un errore, nel qual caso
+ \var{errno} assumerà valori diversi che dipendono dal tipo di operazione,
+ gli unici con signifiato generico sono:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{fd} non è un file aperto.
+ \item[\errcode{EINVAL}] \param{cmd} non è un comando supportato dal kernel
+ corrente.
+ \end{errlist}
+}
+\end{funcproto}
+
+Il primo argomento della funzione è sempre il numero di file descriptor
+\var{fd} su cui si vuole operare. Il comportamento di questa funzione, il
+numero e il tipo degli argomenti, il valore di ritorno e gli eventuali errori
+aggiuntivi, sono determinati dal valore dell'argomento \param{cmd} che in
+sostanza corrisponde all'esecuzione di un determinato \textsl{comando}. A
+seconda del comando specificato il terzo argomento può essere assente (ma se
+specificato verrà ignorato), può assumere un valore intero di tipo
+\ctyp{long}, o essere un puntatore ad una struttura \struct{flock}.
+
+In sez.~\ref{sec:file_dup} abbiamo incontrato un esempio dell'uso di
+\func{fcntl} per la duplicazione dei file descriptor, una lista di tutti i
+possibili valori per \var{cmd}, e del relativo significato, dei codici di
+errore restituiti e del tipo del terzo argomento (cui faremo riferimento con
+il nome indicato nel precedente prototipo), è riportata di seguito:
+\begin{basedescript}{\desclabelwidth{1.8cm}}
+\item[\constd{F\_DUPFD}] trova il primo file descriptor disponibile di valore
+ maggiore o uguale ad \param{arg}, e ne fa un duplicato
+ di \param{fd}, ritorna il nuovo file descriptor in caso di successo e $-1$
+ in caso di errore. Oltre a \errval{EBADF} gli errori possibili sono
+ \errcode{EINVAL} se \param{arg} è negativo o maggiore del massimo consentito
+ o \errcode{EMFILE} se il processo ha già raggiunto il massimo numero di
+ descrittori consentito.
+
+\item[\constd{F\_DUPFD\_CLOEXEC}] ha lo stesso effetto di \const{F\_DUPFD}, ma
+ in più attiva il flag di \textit{close-on-exec} sul file descriptor
+ duplicato, in modo da evitare una successiva chiamata con
+ \const{F\_SETFD}. La funzionalità è stata introdotta con il kernel 2.6.24 ed
+ è prevista nello standard POSIX.1-2008 (si deve perciò definire
+ \macro{\_POSIX\_C\_SOURCE} ad un valore adeguato secondo quanto visto in
+ sez.~\ref{sec:intro_gcc_glibc_std}).
+
+\item[\constd{F\_GETFD}] restituisce il valore dei \textit{file descriptor
+ flags} (vedi sez.~\ref{sec:file_shared_access}) di \param{fd} in caso di
+ successo o $-1$ in caso di errore, il terzo argomento viene ignorato. Non
+ sono previsti errori diversi da \errval{EBADF}. Al momento l'unico flag
+ usato è quello di \textit{close-on-exec}, identificato dalla costante
+ \const{FD\_CLOEXEC}, che serve a richiedere che il file venga chiuso nella
+ esecuzione di una \func{exec} (vedi sez.~\ref{sec:proc_exec}). Un valore
+ nullo significa pertanto che il flag non è impostato.
+
+\item[\constd{F\_SETFD}] imposta il valore dei \textit{file descriptor flags}
+ (vedi sez.~\ref{sec:file_shared_access}) al valore specificato con
+ \param{arg}, ritorna un valore nullo in caso di successo e $-1$ in caso di
+ errore. Non sono previsti errori diversi da \errval{EBADF}. Dato che l'unico
+ flag attualmente usato è quello di \textit{close-on-exec}, identificato
+ dalla costante \const{FD\_CLOEXEC}, tutti gli altri bit di \param{arg},
+ anche se impostati, vengono ignorati.\footnote{questo almeno è quanto
+ avviene fino al kernel 3.2, come si può evincere dal codice della funzione
+ \texttt{do\_fcntl} nel file \texttt{fs/fcntl.c} dei sorgenti del kernel.}
+
+\item[\constd{F\_GETFL}] ritorna il valore dei \textit{file status flags} di
+ \param{fd} in caso di successo o $-1$ in caso di errore, il terzo argomento
+ viene ignorato. Non sono previsti errori diversi da \errval{EBADF}. Il
+ comando permette di rileggere il valore di quei bit
+ dell'argomento \param{flags} di \func{open} che vengono memorizzati nella
+ relativa voce della \textit{file table} all'apertura del file, vale a dire
+ quelli riportati in tab.~\ref{tab:open_access_mode_flag} e
+ tab.~\ref{tab:open_operation_flag}). Si ricordi che quando si usa la
+ funzione per determinare le modalità di accesso con cui è stato aperto il
+ file è necessario estrarre i bit corrispondenti nel \textit{file status
+ flag} con la maschera \const{O\_ACCMODE} come già accennato in
+ sez.~\ref{sec:file_open_close}.
+
+\item[\constd{F\_SETFL}] imposta il valore dei \textit{file status flags} al
+ valore specificato da \param{arg}, ritorna un valore nullo in caso di
+ successo o $-1$ in caso di errore. In generale possono essere impostati solo
+ i flag riportati in tab.~\ref{tab:open_operation_flag}, su Linux si possono
+ modificare soltanto \const{O\_APPEND}, \const{O\_ASYNC}, \const{O\_DIRECT},
+ \const{O\_NOATIME} e \const{O\_NONBLOCK}. Oltre a \errval{EBADF} si otterrà
+ \errcode{EPERM} se si cerca di rimuovere \const{O\_APPEND} da un file
+ marcato come \textit{append-only} o se di cerca di impostare
+ \const{O\_NOATIME} su un file di cui non si è proprietari (e non si hanno i
+ permessi di amministratore) ed \errcode{EINVAL} se si cerca di impostare
+ \const{O\_DIRECT} su un file che non supporta questo tipo di operazioni.
+
+\item[\constd{F\_GETLK}] richiede un controllo sul file lock specificato da
+ \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato,
+ ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Come
+ per i due successivi comandi oltre a \errval{EBADF} se \param{lock} non è un
+ puntatore valido restituisce l'errore generico \errcode{EFAULT}. Questa
+ funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
+
+\item[\constd{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
+ specificato nella struttura puntata da \param{lock}, ritorna un valore nullo
+ in caso di successo e $-1$ se il file lock è tenuto da qualcun altro, nel
+ qual caso si ha un errore di \errcode{EACCES} o \errcode{EAGAIN}. Questa
+ funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
+
+\item[\constd{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
+ la funzione non ritorna subito ma attende che il blocco sia rilasciato, se
+ l'attesa viene interrotta da un segnale la funzione restituisce $-1$ e
+ imposta \var{errno} a \errcode{EINTR}. Questa funzionalità è trattata in
+ dettaglio in sez.~\ref{sec:file_posix_lock}.
+
+\item[\constd{F\_GETOWN}] restituisce in caso di successo l'identificatore del
+ processo o del \textit{process group} (vedi sez.~\ref{sec:sess_proc_group})
+ che è preposto alla ricezione del segnale \signal{SIGIO} (o l'eventuale
+ segnale alternativo impostato con \const{F\_SETSIG}) per gli eventi
+ asincroni associati al file descriptor \param{fd} e del segnale
+ \signal{SIGURG} per la notifica dei dati urgenti di un socket (vedi
+ sez.~\ref{sec:TCP_urgent_data}). Restituisce $-1$ in caso di errore ed il
+ terzo argomento viene ignorato. Non sono previsti errori diversi da
+ \errval{EBADF}.
+
+ Per distinguerlo dal caso in cui il segnale viene inviato a un singolo
+ processo, nel caso di un \textit{process group} viene restituito un valore
+ negativo il cui valore assoluto corrisponde all'identificatore del
+ \textit{process group}. Con Linux questo comporta un problema perché se il
+ valore restituito dalla \textit{system call} è compreso nell'intervallo fra
+ $-1$ e $-4095$ in alcune architetture questo viene trattato dalla
+ \acr{glibc} come un errore,\footnote{il problema deriva dalle limitazioni
+ presenti in architetture come quella dei normali PC (i386) per via delle
+ modalità in cui viene effettuata l'invocazione delle \textit{system call}
+ che non consentono di restituire un adeguato codice di ritorno.} per cui
+ in tal caso \func{fcntl} ritornerà comunque $-1$ mentre il valore restituito
+ dalla \textit{system call} verrà assegnato ad \var{errno}, cambiato di
+ segno.
+
+ Per questo motivo con il kernel 2.6.32 è stato introdotto il comando
+ alternativo \const{F\_GETOWN\_EX}, che vedremo a breve, che consente di
+ evitare il problema. A partire dalla versione 2.11 la \acr{glibc}, se
+ disponibile, usa questa versione alternativa per mascherare il problema
+ precedente e restituire un valore corretto in tutti i casi.\footnote{in cui
+ cioè viene restituito un valore negativo corretto qualunque sia
+ l'identificatore del \textit{process group}, che non potendo avere valore
+ unitario (non esiste infatti un \textit{process group} per \cmd{init}) non
+ può generare ambiguità con il codice di errore.} Questo però comporta che
+ il comportamento del comando può risultare diverso a seconda delle versioni
+ della \acr{glibc} e del kernel.
+
+\item[\constd{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
+ l'identificatore del processo o del \textit{process group} che riceverà i
+ segnali \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
+ descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
+ caso di errore. Oltre a \errval{EBADF} gli errori possibili sono
+ \errcode{ESRCH} se \param{arg} indica un processo o un \textit{process
+ group} inesistente.
+
+ L'impostazione è soggetta alle stesse restrizioni presenti sulla funzione
+ \func{kill} (vedi sez.~\ref{sec:sig_kill_raise}), per cui un utente non
+ privilegiato può inviare i segnali solo ad un processo che gli appartiene,
+ in genere comunque si usa il processo corrente. Come per \const{F\_GETOWN},
+ per indicare un \textit{process group} si deve usare per \param{arg} un
+ valore negativo, il cui valore assoluto corrisponda all'identificatore del
+ \textit{process group}.
+
+ A partire dal kernel 2.6.12 se si sta operando con i \textit{thread} della
+ implementazione nativa di Linux (quella della NTPL, vedi
+ sez.~\ref{sec:linux_ntpl}) e se si è impostato un segnale specifico con
+ \const{F\_SETSIG}, un valore positivo di \param{arg} viene interpretato come
+ indicante un \textit{Thread ID} e non un \textit{Process ID}. Questo
+ consente di inviare il segnale impostato con \const{F\_SETSIG} ad uno
+ specifico \textit{thread}. In genere questo non comporta differenze
+ significative per il processi ordinari, in cui non esistono altri
+ \textit{thread}, dato che su Linux il \textit{thread} principale, che in tal
+ caso è anche l'unico, mantiene un valore del \textit{Thread ID} uguale al
+ \ids{PID} del processo. Il problema è però che questo comportamento non si
+ applica a \signal{SIGURG}, per il quale \param{arg} viene sempre
+ interpretato come l'identificatore di un processo o di un \textit{process
+ group}.
+
+\item[\constd{F\_GETOWN\_EX}] legge nella struttura puntata
+ dall'argomento \param{owner} l'identificatore del processo, \textit{thread}
+ o \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}) che è
+ preposto alla ricezione dei segnali \signal{SIGIO} e \signal{SIGURG} per gli
+ eventi associati al file descriptor \param{fd}. Ritorna un valore nullo in
+ caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF} e da
+ \errval{EFAULT} se \param{owner} non è un puntatore valido.
+
+ Il comando, che è disponibile solo a partire dal kernel 2.6.32, effettua lo
+ stesso compito di \const{F\_GETOWN} di cui costituisce una evoluzione che
+ consente di superare i limiti e le ambiguità relative ai valori restituiti
+ come identificativo. A partire dalla versione 2.11 della \acr{glibc} esso
+ viene usato dalla libreria per realizzare una versione di \func{fcntl} che
+ non presenti i problemi illustrati in precedenza per la versione precedente
+ di \const{F\_GETOWN}. Il comando è specifico di Linux ed utilizzabile solo
+ se si è definita la macro \macro{\_GNU\_SOURCE}.
+
+\item[\constd{F\_SETOWN\_EX}] imposta con il valore della struttura
+ \struct{f\_owner\_ex} puntata \param{owner}, l'identificatore del processo o
+ del \textit{process group} che riceverà i segnali \signal{SIGIO} e
+ \signal{SIGURG} per gli eventi associati al file
+ descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
+ caso di errore, con gli stessi errori di \const{F\_SETOWN} più
+ \errcode{EINVAL} se il campo \var{type} di \struct{f\_owner\_ex} non indica
+ un tipo di identificatore valido.
+
+ \begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{varwidth}[c]{0.5\textwidth}
+ \includestruct{listati/f_owner_ex.h}
+ \end{varwidth}
+ \normalsize
+ \caption{La struttura \structd{f\_owner\_ex}.}
+ \label{fig:f_owner_ex}
+ \end{figure}
+
+ Come \const{F\_GETOWN\_EX} il comando richiede come terzo argomento il
+ puntatore ad una struttura \struct{f\_owner\_ex} la cui definizione è
+ riportata in fig.~\ref{fig:f_owner_ex}, in cui il primo campo indica il tipo
+ di identificatore il cui valore è specificato nel secondo campo, che assume
+ lo stesso significato di \param{arg} per \const{F\_SETOWN}. Per il campo
+ \var{type} i soli valori validi sono \constd{F\_OWNER\_TID},
+ \constd{F\_OWNER\_PID} e \constd{F\_OWNER\_PGRP}, che indicano
+ rispettivamente che si intende specificare con \var{pid} un \textit{Tread
+ ID}, un \textit{Process ID} o un \textit{Process Group ID}. A differenza
+ di \const{F\_SETOWN} se si specifica un \textit{Tread ID} questo riceverà
+ sia \signal{SIGIO} (o il segnale impostato con \const{F\_SETSIG}) che
+ \signal{SIGURG}. Il comando è specifico di Linux, è disponibile solo a
+ partire dal kernel 2.6.32, ed è utilizzabile solo se si è definita la macro
+ \macro{\_GNU\_SOURCE}.
+
+\item[\constd{F\_GETSIG}] restituisce il valore del segnale inviato dai vari
+ meccanismi di I/O asincrono associati al file descriptor \param{fd} (quelli
+ trattati in sez.~\ref{sec:file_asyncronous_operation}) in caso di successo o
+ $-1$ in caso di errore, il terzo argomento viene ignorato. Non sono previsti
+ errori diversi da \errval{EBADF}. Un valore nullo indica che si sta usando
+ il segnale predefinito, che è \signal{SIGIO}. Un valore diverso da zero
+ indica il segnale che è stato impostato con \const{F\_SETSIG}, che può
+ essere anche lo stesso \signal{SIGIO}. Il comando è specifico di Linux ed
+ utilizzabile solo se si è definita la macro \macro{\_GNU\_SOURCE}.
+
+\item[\constd{F\_SETSIG}] imposta il segnale inviato dai vari meccanismi di
+ I/O asincrono associati al file descriptor \param{fd} (quelli trattati in
+ sez.~\ref{sec:file_asyncronous_operation}) al valore indicato
+ da \param{arg}, ritorna un valore nullo in caso di successo o $-1$ in caso
+ di errore. Oltre a \errval{EBADF} gli errori possibili sono
+ \errcode{EINVAL} se \param{arg} indica un numero di segnale non valido. Un
+ valore nullo di \param{arg} indica di usare il segnale predefinito, cioè
+ \signal{SIGIO}. Un valore diverso da zero, compreso lo stesso
+ \signal{SIGIO}, specifica il segnale voluto. Il comando è specifico di
+ Linux ed utilizzabile solo se si è definita la macro \macro{\_GNU\_SOURCE}.
+
+ L'impostazione di un valore diverso da zero permette inoltre, se si è
+ installato il gestore del segnale come \var{sa\_sigaction} usando
+ \const{SA\_SIGINFO}, (vedi sez.~\ref{sec:sig_sigaction}), di rendere
+ disponibili al gestore informazioni ulteriori riguardo il file che ha
+ generato il segnale attraverso i valori restituiti in
+ \struct{siginfo\_t}. Se inoltre si imposta un segnale \textit{real-time} si
+ potranno sfruttare le caratteristiche di avanzate di questi ultimi (vedi
+ sez.~\ref{sec:sig_real_time}), ed in particolare la capacità di essere
+ accumulati in una coda prima della notifica.
+
+\item[\constd{F\_GETLEASE}] restituisce il tipo di \textit{file lease} che il
+ processo detiene nei confronti del file descriptor \var{fd} o $-1$ in caso
+ di errore, il terzo argomento viene ignorato. Non sono previsti errori
+ diversi da \errval{EBADF}. Il comando è specifico di Linux ed utilizzabile
+ solo se si è definita la macro \macro{\_GNU\_SOURCE}. Questa funzionalità è
+ trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
+
+\item[\constd{F\_SETLEASE}] imposta o rimuove a seconda del valore
+ di \param{arg} un \textit{file lease} sul file descriptor \var{fd} a seconda
+ del valore indicato da \param{arg}. Ritorna un valore nullo in caso di
+ successo o $-1$ in caso di errore. Oltre a \errval{EBADF} si otterrà
+ \errcode{EINVAL} se si è specificato un valore non valido per \param{arg}
+ (deve essere usato uno dei valori di tab.~\ref{tab:file_lease_fctnl}),
+ \errcode{ENOMEM} se non c'è memoria sufficiente per creare il \textit{file
+ lease}, \errcode{EACCES} se non si è il proprietario del file e non si
+ hanno i privilegi di amministratore.\footnote{per la precisione occorre la
+ capacità \const{CAP\_LEASE}.}
+
+ Il supporto il supporto per i \textit{file lease}, che consente ad un
+ processo che detiene un \textit{lease} su un file di riceve una notifica
+ qualora un altro processo cerchi di eseguire una \func{open} o una
+ \func{truncate} su di esso è stato introdotto a partire dai kernel della
+ serie 2.4 Il comando è specifico di Linux ed utilizzabile solo se si è
+ definita la macro \macro{\_GNU\_SOURCE}. Questa funzionalità è trattata in
+ dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
+
+\item[\constd{F\_NOTIFY}] attiva il meccanismo di notifica asincrona per cui
+ viene riportato al processo chiamante, tramite il segnale \signal{SIGIO} (o
+ altro segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
+ direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file
+ in essa contenuti; ritorna un valore nullo in caso di successo o $-1$ in
+ caso di errore. Il comando è specifico di Linux ed utilizzabile solo se si è
+ definita la macro \macro{\_GNU\_SOURCE}. Questa funzionalità, disponibile
+ dai kernel della serie 2.4.x, è trattata in dettaglio in
+ sez.~\ref{sec:file_asyncronous_lease}.
+
+\item[\constd{F\_GETPIPE\_SZ}] restituisce in caso di successo la dimensione
+ del buffer associato alla \textit{pipe} \param{fd} (vedi
+ sez.~\ref{sec:ipc_pipes}) o $-1$ in caso di errore, il terzo argomento viene
+ ignorato. Non sono previsti errori diversi da \errval{EBADF}, che viene
+ restituito anche se il file descriptor non è una \textit{pipe}. Il comando è
+ specifico di Linux, è disponibile solo a partire dal kernel 2.6.35, ed è
+ utilizzabile solo se si è definita la macro \macro{\_GNU\_SOURCE}.
+
+\item[\constd{F\_SETPIPE\_SZ}] imposta la dimensione del buffer associato alla
+ \textit{pipe} \param{fd} (vedi sez.~\ref{sec:ipc_unix}) ad un valore uguale
+ o superiore a quello indicato dall'argomento \param{arg}. Ritorna un valore
+ nullo in caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF}
+ gli errori possibili sono \errcode{EBUSY} se si cerca di ridurre la
+ dimensione del buffer al di sotto della quantità di dati effettivamente
+ presenti su di esso ed \errcode{EPERM} se un processo non privilegiato cerca
+ di impostare un valore troppo alto. La dimensione minima del buffer è pari
+ ad una pagina di memoria, a cui verrà comunque arrotondata ogni dimensione
+ inferiore, il valore specificato viene in genere arrotondato per eccesso al
+ valore ritenuto più opportuno dal sistema, pertanto una volta eseguita la
+ modifica è opportuno rileggere la nuova dimensione con
+ \const{F\_GETPIPE\_SZ}. I processi non privilegiati\footnote{per la
+ precisione occorre la capacità \const{CAP\_SYS\_RESOURCE}.} non possono
+ impostare un valore superiore a quello indicato da
+ \sysctlfiled{fs/pipe-size-max}. Il comando è specifico di Linux, è
+ disponibile solo a partire dal kernel 2.6.35, ed è utilizzabile solo se si è
+ definita la macro \macro{\_GNU\_SOURCE}.
+
+\end{basedescript}
+
+% TODO: trattare RWH_WRITE_LIFE_EXTREME e RWH_WRITE_LIFE_SHORT aggiunte con
+% il kernel 4.13 (vedi https://lwn.net/Articles/727385/)
+
+La maggior parte delle funzionalità controllate dai comandi di \func{fcntl}
+sono avanzate e richiedono degli approfondimenti ulteriori, saranno pertanto
+riprese più avanti quando affronteremo le problematiche ad esse relative. In
+particolare le tematiche relative all'I/O asincrono e ai vari meccanismi di
+notifica saranno trattate in maniera esaustiva in
+sez.~\ref{sec:file_asyncronous_operation} mentre quelle relative al
+\textit{file locking} saranno esaminate in sez.~\ref{sec:file_locking}). L'uso
+di questa funzione con i socket verrà trattato in
+sez.~\ref{sec:sock_ctrl_func}.
+
+La gran parte dei comandi di \func{fcntl} (come \const{F\_DUPFD},
+\const{F\_GETFD}, \const{F\_SETFD}, \const{F\_GETFL}, \const{F\_SETFL},
+\const{F\_GETLK}, \const{F\_SETLK} e \const{F\_SETLKW}) sono previsti da SVr4
+e 4.3BSD e standardizzati in POSIX.1-2001 che inoltre prevede gli ulteriori
+\const{F\_GETOWN} e \const{F\_SETOWN}. Pertanto nell'elenco si sono indicate
+esplicitamente soltanto le ulteriori richieste in termini delle macro di
+funzionalità di sez.~\ref{sec:intro_gcc_glibc_std} soltanto per le
+funzionalità inserite in standard successivi o specifiche di Linux.
+
+
+% \subsection{La funzione \func{ioctl}}
+% \label{sec:file_ioctl}
+
+Benché l'interfaccia di gestione dell'I/O sui file di cui abbiamo parlato
+finora si sia dimostrata valida anche per l'interazione diretta con le
+periferiche attraverso i loro file di dispositivo, consentendo di usare le
+stesse funzioni utilizzate per i normali file di dati, esistono però
+caratteristiche peculiari, specifiche dell'hardware e delle funzionalità che
+ciascun dispositivo può provvedere, che non possono venire comprese in questa
+interfaccia astratta come ad esempio l'impostazione della velocità di una
+porta seriale, o le dimensioni di un framebuffer.