già.
\item \macro{EMLINK} ci sono troppi link al file \var{oldpath} (il
numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi
- \secref{sec:xxx_limits}).
+ \secref{sec:sys_limits}).
\end{errlist}
ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOTDIR},
\macro{EFAULT}, \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP},
Una delle caratteristiche di queste funzioni è che la creazione/rimozione
della nome dalla directory e l'incremento/decremento del numero di riferimenti
-nell'inode deve essere una operazione atomica (cioè non interrompibile da
-altri processi), per questo entrambe queste funzioni sono realizzate tramite
-una singola system call.
+nell'inode deve essere una operazione atomica (si veda
+\secref{cha:proc_atom_oper}), per questo entrambe queste funzioni sono
+realizzate tramite una singola system call.
Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
\begin{figure}[htb]
\centering
- \includegraphics[width=5cm]{img/link_loop.eps}
+ \includegraphics[width=5cm]{img/link_loop}
\caption{Esempio di loop nel filesystem creato con un link simbolico.}
\label{fig:file_link_loop}
\end{figure}
fatta per compatibilità all'indietro con BSD, che non consente di specificare
la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
dimensione superiore a \macro{PATH\_MAX} (di solito 256 byte, vedi
-\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
+\secref{sec:sys_limits}); il problema è che in Linux non esiste una dimensione
superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
contenere il nome del file, e questa è la ragione principale per cui questa
funzione è deprecata.