-che non segue più lo standard per cui l'\textit{hard link} viene creato
-rispetto al link simbolico, e non al file cui questo punta.
-
-La ragione di questa differenza rispetto allo standard, presente anche in
-altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
-riferimento anche ad un file non esistente o a una directory, per i quali
-l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
-link simbolico è stata ritenuta una scelta scorretta nella progettazione
-dell'interfaccia. Infatti se non ci fosse il comportamento adottato da Linux
-sarebbe impossibile creare un \textit{hard link} ad un link simbolico, perché
-la funzione lo risolverebbe e l'\textit{hard link} verrebbe creato verso la
-destinazione. Invece evitando di seguire lo standard l'operazione diventa
-possibile, ed anche il comportamento della funzione risulta molto più
-comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
- link} rispetto alla destinazione di un link simbolico è sempre possibile
-farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
- standard possa causare problemi, come nell'esempio descritto nell'articolo
- citato nella nota precedente, a programmi che non si aspettano questa
- differenza rispetto allo standard POSIX.}
-
-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{funcproto}{
-\fhead{unistd.h}
-\fdecl{int unlink(const char *pathname)}
-\fdesc{Cancella un file.}
-}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
- nel qual caso \var{errno} assumerà uno dei valori:
- \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} nel loro significato generico.}
-\end{funcproto}
-
-\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 \itindex{inode}
-\textit{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
-\itindex{inode} nell'\textit{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 \itindex{inode} nell'\textit{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
- \itindex{inode} \textit{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'\textit{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{funcproto}{
-\fhead{stdio.h}
-\fdecl{int remove(const char *pathname)}
-\fdesc{Cancella un nome dal filesystem.}
-}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà uno dei valori relativi alla chiamata utilizzata,
- pertanto si può fare riferimento a quanto illustrato nelle descrizioni di
- \func{unlink} e \func{rmdir}.}
-\end{funcproto}
-
-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{funcproto}{
-\fhead{stdio.h}
-\fdecl{int rename(const char *oldpath, const char *newpath)}
-\fdesc{Rinomina un file.}
-}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
- nel qual caso \var{errno} assumerà uno dei valori:
- \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 \index{directory~di~lavoro} directory di
- lavoro o come radice) o del sistema (come \itindex{mount~point}
- \textit{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 \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} nel loro significato generico.}
-\end{funcproto}
-
-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 \itindex{inode} \textit{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'\textit{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 è:
-
+che non segue più lo standard per cui l'\textit{hard link} viene creato nei
+confronti del collegamento simbolico, e non del file cui questo punta. La
+revisione POSIX.1-2008 lascia invece il comportamento dipendente
+dall'implementazione, cosa che rende Linux conforme a questa versione
+successiva dello standard.
+
+\itindbeg{symbolic~link}
+
+\index{collegamento!simbolico|(}
+
+La ragione di questa differenza rispetto al vecchio standard, presente anche
+in altri sistemi unix-like, è dovuta al fatto che un collegamento simbolico
+può fare riferimento anche ad un file non esistente o a una directory, per i
+quali l'\textit{hard link} non può essere creato, per cui la scelta di seguire
+il collegamento simbolico è stata ritenuta una scelta scorretta nella
+progettazione dell'interfaccia. Infatti se non ci fosse il comportamento
+adottato da Linux sarebbe impossibile creare un \textit{hard link} ad un
+collegamento simbolico, perché la funzione lo risolverebbe e l'\textit{hard
+ link} verrebbe creato verso la destinazione. Invece evitando di seguire lo
+standard l'operazione diventa possibile, ed anche il comportamento della
+funzione risulta molto più comprensibile. Tanto più che se proprio se si vuole
+creare un \textit{hard link} rispetto alla destinazione di un collegamento
+simbolico è sempre possibile farlo direttamente.\footnote{ciò non toglie che
+ questo comportamento possa causare problemi, come nell'esempio descritto
+ nell'articolo citato nella nota precedente, a programmi che non si aspettano
+ questa differenza rispetto allo standard POSIX.}
+
+Dato che \func{link} crea semplicemente dei nomi che fanno riferimenti agli
+\itindex{inode} \textit{inode}, essa 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 collegamento
+diretto ad una directory.
+
+Per ovviare a queste limitazioni, come accennato all'inizio, i sistemi
+unix-like supportano un'altra forma di collegamento, detta
+``\textsl{collegamento simbolico}'' (o anche \textit{soft link} o
+\textit{symbolic link}). In questo caso si tratta, come avviene in altri
+sistemi operativi, di file speciali che contengono semplicemente il
+riferimento ad un altro file (o directory). In questo modo è possibile
+effettuare \textit{link} anche attraverso filesystem diversi, a file posti in
+filesystem che non supportano i collegamenti diretti, a delle directory, ed
+anche a file che non esistono ancora.
+
+\itindend{hard~link}
+\index{collegamento!diretto|)}
+
+Il meccanismo funziona in quanto i \textit{symbolic link} 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'\textit{inode}
+ e riconoscibile dal valore del campo \var{st\_mode} della struttura
+ \struct{stat} (vedi sez.~\ref{sec:file_stat}).} e tutta una serie di
+funzioni di sistema (come \func{open} o \func{stat}) quando ricevono come
+argomento il \textit{pathname} di un collegamento simbolico vanno
+automaticamente ad operare sul file da esso specificato. La funzione di
+sistema che permette di creare un nuovo collegamento simbolico è
+\funcd{symlink}, ed il suo prototipo è: