+La funzione crea sul \itindex{pathname}\textit{pathname} \param{newpath} un
+collegamento diretto al file indicato da \param{oldpath}. Per quanto detto la
+creazione di un nuovo collegamento diretto non copia il contenuto del file, ma
+si limita a creare una voce nella directory specificata da \param{newpath} e
+ad aumentare di uno il numero di riferimenti al file (riportato nel campo
+\var{st\_nlink} della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat})
+aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
+essere così chiamato con vari nomi in diverse directory.
+
+Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
+collegamento diretto è possibile solo se entrambi i
+\itindex{pathname}\textit{pathname} sono nello stesso filesystem; inoltre il
+filesystem deve supportare i collegamenti diretti (il meccanismo non è
+disponibile ad esempio con il filesystem \acr{vfat} di Windows).
+
+La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
+filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
+l'amministratore è in grado di creare un collegamento diretto ad un'altra
+directory: questo viene fatto perché con una tale operazione è possibile
+creare dei \textit{loop} nel filesystem (vedi l'esempio mostrato in
+sez.~\ref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi
+non sono in grado di gestire e la cui rimozione diventerebbe estremamente
+complicata (in genere per questo tipo di errori occorre far girare il
+programma \cmd{fsck} per riparare il filesystem).
+
+Data la pericolosità di questa operazione e la disponibilità dei link
+simbolici che possono fornire la stessa funzionalità senza questi problemi,
+nei filesystem usati in Linux questa caratteristica è stata completamente
+disabilitata, e al tentativo di creare un link diretto ad una directory la
+funzione restituisce l'errore \errcode{EPERM}.
+
+La rimozione di un file (o più precisamente della voce che lo referenzia
+all'interno di una directory) si effettua con la funzione \funcd{unlink}; il
+suo prototipo è il seguente:
+\begin{prototype}{unistd.h}{int unlink(const char *pathname)}
+
+ Cancella un file.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ errore, nel qual caso il file non viene toccato. La variabile
+ \var{errno} viene impostata secondo i seguenti codici di errore:
+ \begin{errlist}
+ \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una directory.
+ \footnotemark
+ \item[\errcode{EROFS}] \param{pathname} è su un filesystem montato in sola
+ lettura.
+ \item[\errcode{EISDIR}] \param{pathname} fa riferimento a una directory.
+ \end{errlist}
+ ed inoltre: \errval{EACCES}, \errval{EFAULT}, \errval{ENOENT},
+ \errval{ENOTDIR}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP},
+ \errval{EIO}.}
+\end{prototype}
+
+\footnotetext{questo è un valore specifico ritornato da Linux che non consente
+ l'uso di \func{unlink} con le directory (vedi sez.~\ref{sec:file_remove}).
+ Non è conforme allo standard POSIX, che prescrive invece l'uso di
+ \errcode{EPERM} in caso l'operazione non sia consentita o il processo non
+ abbia privilegi sufficienti.}
+
+La funzione cancella il nome specificato da \param{pathname} nella relativa
+directory e decrementa il numero di riferimenti nel relativo
+inode\index{inode}. Nel caso di link simbolico cancella il link simbolico; nel
+caso di socket, fifo o file di dispositivo\index{file!di~dispositivo} rimuove
+il nome, ma come per i file i processi che hanno aperto uno di questi oggetti
+possono continuare ad utilizzarlo.
+
+Per cancellare una voce in una directory è necessario avere il permesso di
+scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
+il diritto di esecuzione sulla directory che la contiene (affronteremo in
+dettaglio l'argomento dei permessi di file e directory in
+sez.~\ref{sec:file_access_control}). Se inoltre lo \itindex{sticky~bit}
+\textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}) è impostato
+occorrerà anche essere proprietari del file o proprietari della directory (o
+root, per cui nessuna delle restrizioni è applicata).
+
+Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
+nome dalla directory e l'incremento/decremento del numero di riferimenti
+nell'inode\index{inode} devono essere effettuati in maniera atomica (si veda
+sez.~\ref{sec:proc_atom_oper}) senza possibili interruzioni fra le due
+operazioni. Per questo entrambe queste funzioni sono realizzate tramite una
+singola system call.
+
+Si ricordi infine che un file non viene eliminato dal disco fintanto che tutti
+i riferimenti ad esso sono stati cancellati: solo quando il \textit{link
+ count} mantenuto nell'inode\index{inode} diventa zero lo spazio occupato su
+disco viene rimosso (si ricordi comunque che a questo si aggiunge sempre
+un'ulteriore condizione,\footnote{come vedremo in
+ cap.~\ref{cha:file_unix_interface} il kernel mantiene anche una tabella dei
+ file aperti nei vari processi, che a sua volta contiene i riferimenti agli
+ \index{inode} inode ad essi relativi. Prima di procedere alla cancellazione
+ dello spazio occupato su disco dal contenuto di un file il kernel controlla
+ anche questa tabella, per verificare che anche in essa non ci sia più nessun
+ riferimento all'inode in questione.} e cioè che non ci siano processi che
+abbiano il suddetto file aperto).
+
+Questa proprietà viene spesso usata per essere sicuri di non lasciare file
+temporanei su disco in caso di crash dei programmi; la tecnica è quella di
+aprire il file e chiamare \func{unlink} subito dopo, in questo modo il
+contenuto del file è sempre disponibile all'interno del processo attraverso il
+suo file descriptor (vedi sez.~\ref{sec:file_fd}) fintanto che il processo non
+chiude il file, ma non ne resta traccia in nessuna directory, e lo spazio
+occupato su disco viene immediatamente rilasciato alla conclusione del
+processo (quando tutti i file vengono chiusi).
+
+
+\subsection{Le funzioni \func{remove} e \func{rename}}
+\label{sec:file_remove}
+
+Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
+\func{unlink} sulle directory; per cancellare una directory si può usare la
+funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}), oppure la
+funzione \funcd{remove}.
+
+Questa è la funzione prevista dallo standard ANSI C per cancellare un file o
+una directory (e funziona anche per i sistemi che non supportano i link
+diretti). Per i file è identica a \func{unlink} e per le directory è identica
+a \func{rmdir}; il suo prototipo è:
+\begin{prototype}{stdio.h}{int remove(const char *pathname)}
+ Cancella un nome dal filesystem.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ errore, nel qual caso il file non viene toccato.
+
+ I codici di errore riportati in \var{errno} sono quelli della chiamata
+ utilizzata, pertanto si può fare riferimento a quanto illustrato nelle
+ descrizioni di \func{unlink} e \func{rmdir}.}
+\end{prototype}
+
+La funzione utilizza la funzione \func{unlink}\footnote{questo vale usando le
+ \acr{glibc}; nelle libc4 e nelle libc5 la funzione \func{remove} è un
+ semplice alias alla funzione \func{unlink} e quindi non può essere usata per
+ le directory.} per cancellare i file e la funzione \func{rmdir} per
+cancellare le directory; si tenga presente che per alcune implementazioni del
+protocollo NFS utilizzare questa funzione può comportare la scomparsa di file
+ancora in uso.
+
+Per cambiare nome ad un file o a una directory (che devono comunque essere
+nello stesso filesystem) si usa invece la funzione \funcd{rename},\footnote{la
+ funzione è definita dallo standard ANSI C, ma si applica solo per i file, lo
+ standard POSIX estende la funzione anche alle directory.} il cui prototipo
+è:
+\begin{prototype}{stdio.h}
+ {int rename(const char *oldpath, const char *newpath)}
+
+ Rinomina un file.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ errore, nel qual caso il file non viene toccato. La variabile
+ \var{errno} viene impostata secondo i seguenti codici di errore:
+ \begin{errlist}
+ \item[\errcode{EISDIR}] \param{newpath} è una directory mentre
+ \param{oldpath} non è una directory.
+ \item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo
+ stesso filesystem.
+ \item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
+ non vuota.
+ \item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
+ parte di qualche processo (come directory di lavoro o come radice) o del
+ sistema (come mount point).
+ \item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
+ \param{oldpath} o più in generale si è cercato di creare una directory come
+ sotto-directory di se stessa.
+ \item[\errcode{ENOTDIR}] Uno dei componenti dei
+ \itindex{pathname}\textit{pathname} non è una directory o \param{oldpath}
+ è una directory e \param{newpath} esiste e non è una directory.
+ \end{errlist}
+ ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
+ \errval{ENOENT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP} e
+ \errval{ENOSPC}.}
+\end{prototype}
+
+La funzione rinomina il file \param{oldpath} in \param{newpath}, eseguendo se
+necessario lo spostamento di un file fra directory diverse. Eventuali altri
+link diretti allo stesso file non vengono influenzati.
+
+Il comportamento della funzione è diverso a seconda che si voglia rinominare
+un file o una directory; se ci riferisce ad un file allora \param{newpath}, se
+esiste, non deve essere una directory (altrimenti si ha l'errore
+\errcode{EISDIR}). Nel caso \param{newpath} indichi un file esistente questo
+viene cancellato e rimpiazzato (atomicamente).
+
+Se \param{oldpath} è una directory allora \param{newpath}, se esiste, deve
+essere una directory vuota, altrimenti si avranno gli errori \errcode{ENOTDIR}
+(se non è una directory) o \errcode{ENOTEMPTY} (se non è vuota). Chiaramente
+\param{newpath} non può contenere \param{oldpath} altrimenti si avrà un errore
+\errcode{EINVAL}.
+
+Se \param{oldpath} si riferisce ad un link simbolico questo sarà rinominato; se
+\param{newpath} è un link simbolico verrà cancellato come qualunque altro
+file. Infine qualora \param{oldpath} e \param{newpath} siano due nomi dello
+stesso file lo standard POSIX prevede che la funzione non dia errore, e non
+faccia nulla, lasciando entrambi i nomi; Linux segue questo standard, anche
+se, come fatto notare dal manuale delle \textit{glibc}, il comportamento più
+ragionevole sarebbe quello di cancellare \param{oldpath}.
+
+Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di
+\func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
+può esistere cioè nessun istante in cui un altro processo può trovare attivi
+entrambi i nomi dello stesso file, o, in caso di sostituzione di un file
+esistente, non trovare quest'ultimo prima che la sostituzione sia stata
+eseguita.
+
+In ogni caso se \param{newpath} esiste e l'operazione fallisce per un qualche
+motivo (come un crash del kernel), \func{rename} garantisce di lasciare
+presente un'istanza di \param{newpath}. Tuttavia nella sovrascrittura potrà
+esistere una finestra in cui sia \param{oldpath} che \param{newpath} fanno
+riferimento allo stesso file.
+
+
+\subsection{I link simbolici}
+\label{sec:file_symlink}
+
+Come abbiamo visto in sez.~\ref{sec:file_link} la funzione \func{link} crea
+riferimenti agli \index{inode}inode, pertanto può funzionare soltanto per file
+che risiedono sullo stesso filesystem e solo per un filesystem di tipo Unix.
+Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto
+ad una directory.
+
+Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
+link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
+come avviene in altri sistemi operativi, dei file speciali che contengono
+semplicemente il riferimento ad un altro file (o directory). In questo modo è
+possibile effettuare link anche attraverso filesystem diversi, a file posti in
+filesystem che non supportano i link diretti, a delle directory, ed anche a
+file che non esistono ancora.
+
+Il sistema funziona in quanto i link simbolici sono riconosciuti come tali dal
+kernel\footnote{è uno dei diversi tipi di file visti in
+ tab.~\ref{tab:file_file_types}, contrassegnato come tale nell'inode, e
+ riconoscibile dal valore del campo \var{st\_mode} della struttura
+ \struct{stat} (vedi sez.~\ref{sec:file_stat}).} per cui alcune funzioni di
+libreria (come \func{open} o \func{stat}) quando ricevono come argomento un
+link simbolico vengono automaticamente applicate al file da esso specificato.
+La funzione che permette di creare un nuovo link simbolico è \funcd{symlink},
+ed il suo prototipo è:
+\begin{prototype}{unistd.h}
+ {int symlink(const char *oldpath, const char *newpath)}
+ Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
+ \param{oldpath}.
+
+ \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
+ errore, nel qual caso la variabile \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] il filesystem che contiene \param{newpath} non
+ supporta i link simbolici.
+ \item[\errcode{ENOENT}] una componente di \param{newpath} non esiste o
+ \param{oldpath} è una stringa vuota.
+ \item[\errcode{EEXIST}] esiste già un file \param{newpath}.
+ \item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
+ lettura.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
+ \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP}, \errval{ENOSPC} e
+ \errval{EIO}.}
+\end{prototype}
+
+Si tenga presente che la funzione non effettua nessun controllo sull'esistenza
+di un file di nome \param{oldpath}, ma si limita ad inserire quella stringa
+nel link simbolico. Pertanto un link simbolico può anche riferirsi ad un file
+che non esiste: in questo caso si ha quello che viene chiamato un
+\textit{dangling link}, letteralmente un \textsl{link ciondolante}.
+
+Come accennato i link simbolici sono risolti automaticamente dal kernel
+all'invocazione delle varie system call; in tab.~\ref{tab:file_symb_effect} si
+è riportato un elenco dei comportamenti delle varie funzioni di libreria che
+operano sui file nei confronti della risoluzione dei link simbolici,
+specificando quali seguono il link simbolico e quali invece possono operare
+direttamente sul suo contenuto.