+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, una modalità per evitare i rischi
+ illustrati in precedenza se si sta usando il filesystem \textit{proc}.}
+\includecodesnip{listati/procfd_linkat.c}
+
+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, qualunque siano i permessi del processo e che si usi questo approccio
+o \const{AT\_EMPTY\_PATH}, con un errore di \errval{ENOENT}.
+
+Questo non avviene se il file descriptor sorgente è stato ottenuto con
+\const{O\_TMPFILE} e la funzione ha successo, a meno che non si sia usato
+nell'apertura anche \const{O\_EXCL} per impedire questo specifico
+comportamento, e continuare ad ottenere l'errore di \errval{ENOENT}. In fig.
+
+Pertanto la modalità per creare in maniera sicura la versione iniziale di un
+file cui abbiamo accennato a pag.~\pageref{open_o_tmpfile_flag},
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/initfile.c}
+ \end{minipage}
+ \caption{Esempio di codice creare in maniera sicura il contenuto iniziale di
+ un file.}
+ \label{fig:initfile}
+\end{figure}
+
+
+
+
+
+
+% TODO: Trattare esempio di inzializzazione di file e successivo collegamento
+% con l'uso di O_TMPFILE e linkat, vedi man open
+
+
+
+% TODO manca prototipo di renameat2, introdotta nel 3.15, vedi
+% http://lwn.net/Articles/569134/
+