+ \item[\errcode{EBUSY}] il filesystem è occupato.
+ \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point}.
+ \item[\errcode{EPERM}] il processo non ha i privilegi di
+ amministratore.\footnotemark
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{ENOMEM} nel loro significato generico. }
+\end{funcproto}
+
+\footnotetext{più precisamente la capacità \const{CAP\_SYS\_ADMIN}, vedi
+ sez.~\ref{sec:proc_capabilities}.}
+
+La funzione prende il nome della directory su cui il filesystem è montato e
+non il file o il dispositivo che è stato montato,\footnote{questo è vero a
+ partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la
+ funzione poteva essere usata anche specificando il file di dispositivo.} in
+quanto a partire dai kernel della serie 2.4.x è possibile montare lo stesso
+dispositivo in più punti. Nel caso più di un filesystem sia stato montato
+sullo stesso \textit{mount point} viene smontato quello che è stato montato
+per ultimo. Si tenga presente che la funzione fallisce se il filesystem è
+``\textsl{occupato}'', cioè quando ci sono ancora dei file aperti sul
+filesystem, se questo contiene la directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}) di un qualunque processo o il \textit{mount
+ point} di un altro filesystem.
+
+Linux provvede inoltre una seconda funzione di sistema, \funcd{umount2}, che
+consente un maggior controllo delle operazioni, come forzare lo smontaggio di
+un filesystem anche quando questo risulti occupato; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/mount.h}
+\fdecl{umount2(const char *target, int flags)}
+\fdesc{Smonta un filesystem.}
+}
+{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{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
+ ed il filesystem non era occupato.
+ \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
+ processo, o contiene dei file aperti, o un altro \textit{mount point}.
+ \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point} o si
+ è usato \const{MNT\_EXPIRE} con \const{MNT\_FORCE} o
+ \const{MNT\_DETACH} o si è specificato un flag non esistente.
+ \end{errlist}
+ e tutti gli altri valori visti per \func{umount} con lo stesso significato.}
+\end{funcproto}
+
+Il valore di \param{flags} è una maschera binaria dei flag che controllano le
+modalità di smontaggio, che deve essere specificato con un OR aritmetico delle
+costanti illustrate in tab.~\ref{tab:umount2_flags}. Specificando
+\constd{MNT\_FORCE} la funzione cercherà di liberare il filesystem anche se è
+occupato per via di una delle condizioni descritte in precedenza. A seconda
+del tipo di filesystem alcune (o tutte) possono essere superate, evitando
+l'errore di \errcode{EBUSY}. In tutti i casi prima dello smontaggio viene
+eseguita una sincronizzazione dei dati.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Descrizione}\\
+ \hline
+ \hline
+ \const{MNT\_FORCE} & Forza lo smontaggio del filesystem anche se questo è
+ occupato (presente dai kernel della serie 2.2).\\
+ \const{MNT\_DETACH} & Esegue uno smontaggio ``\textsl{pigro}'', in cui si
+ blocca l'accesso ma si aspetta che il filesystem si
+ liberi (presente dal kernel 2.4.11 e dalla
+ \acr{glibc} 2.11).\\
+ \const{MNT\_EXPIRE} & Se non occupato marca un \textit{mount point} come
+ ``\textsl{in scadenza}'' in modo che ad una
+ successiva chiamata senza utilizzo del filesystem
+ questo venga smontato (presente dal
+ kernel 2.6.8 e dalla \acr{glibc} 2.11).\\
+ \const{UMOUNT\_NOFOLLOW}& Non dereferenzia \param{target} se questo è un
+ collegamento simbolico (vedi
+ sez.~\ref{sec:link_symlink_rename}) evitando
+ problemi di sicurezza (presente dal kernel
+ 2.6.34).\\
+ \hline
+ \end{tabular}
+ \caption{Costanti che identificano i bit dell'argomento \param{flags}
+ della funzione \func{umount2}.}
+ \label{tab:umount2_flags}
+\end{table}
+
+Con l'opzione \constd{MNT\_DETACH} si richiede invece uno smontaggio
+``\textsl{pigro}'' (o \textit{lazy umount}) in cui il filesystem diventa
+inaccessibile per i nuovi processi subito dopo la chiamata della funzione, ma
+resta accessibile per quelli che lo hanno ancora in uso e non viene smontato
+fintanto che resta occupato.
+
+Con \constd{MNT\_EXPIRE}, che non può essere specificato insieme agli altri
+due, si marca il \textit{mount point} di un filesystem non occupato come
+``\textsl{in scadenza}'', in tal caso \func{umount2} ritorna con un errore di
+\errcode{EAGAIN}, mentre in caso di filesystem occupato si sarebbe ricevuto
+\errcode{EBUSY}. Una volta marcato, se nel frattempo non viene fatto nessun
+uso del filesystem, ad una successiva chiamata con \const{MNT\_EXPIRE} questo
+verrà smontato. Questo flag consente di realizzare un meccanismo che smonti
+automaticamente i filesystem che restano inutilizzati per un certo periodo di
+tempo.
+
+Infine il flag \constd{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se
+questo è un collegamento simbolico (vedi
+sez.~\ref{sec:link_symlink_rename}). Questa è una misura di sicurezza
+introdotta per evitare, per quei filesystem per il quale è prevista una
+gestione diretta da parte degli utenti, come quelli basati su \itindex{FUSE}
+FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
+ interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
+ di implementarne le funzioni in \textit{user space}, così da rendere
+ possibile l'implementazione di un qualunque filesystem (con applicazioni di
+ grande interesse come il filesystem cifrato \textit{encfs} o il filesystem
+ di rete \textit{sshfs}) che possa essere usato direttamente per conto degli
+ utenti.} che si possano passare ai programmi che effettuano lo smontaggio
+dei filesystem, che in genere sono privilegiati ma consentono di agire solo
+sui propri \textit{mount point}, dei collegamenti simbolici che puntano ad
+altri \textit{mount point}, ottenendo così la possibilità di smontare
+qualunque filesystem.
+
+
+Altre due funzioni di sistema specifiche di Linux,\footnote{esse si trovano
+ anche su BSD, ma con una struttura diversa.} utili per ottenere in maniera
+diretta informazioni riguardo al filesystem su cui si trova un certo file,
+sono \funcd{statfs} e \funcd{fstatfs}, i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/vfs.h}
+\fdecl{int statfs(const char *path, struct statfs *buf)}
+\fdecl{int fstatfs(int fd, struct statfs *buf)}
+\fdesc{Restituiscono informazioni relative ad un filesystem.}
+}
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato
+ non supporta la funzione.
+ \end{errlist} ed inoltre \errval{EFAULT} ed \errval{EIO} per entrambe,
+ \errval{EBADF} per \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{EACCES}, \errval{ELOOP} per \func{statfs} nel loro
+ significato generico.}
+\end{funcproto}
+
+Queste funzioni permettono di ottenere una serie di informazioni generali
+riguardo al filesystem su cui si trova il file specificato con un
+\textit{pathname} per \func{statfs} e con un file descriptor (vedi
+sez.~\ref{sec:file_fd}) per \func{statfs}. Le informazioni vengono restituite
+all'indirizzo \param{buf} di una struttura \struct{statfs} definita come in
+fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il filesystem in
+esame sono impostati a zero. I valori del campo \var{f\_type} sono definiti
+per i vari filesystem nei relativi file di header dei sorgenti del kernel da
+costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in genere è il nome
+del filesystem stesso.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/statfs.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{statfs}.}
+ \label{fig:sys_statfs}
+\end{figure}
+
+\conffilebeg{/etc/mtab}
+
+La \acr{glibc} provvede infine una serie di funzioni per la gestione dei due
+file \conffiled{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
+ \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
+ed \conffile{/etc/mtab}\footnote{più precisamente \funcm{setmntent},
+ \funcm{getmntent},\funcm{getmntent\_r}, \funcm{addmntent},\funcm{endmntent},
+ \funcm{hasmntopt}.} che convenzionalmente sono usati in quasi tutti i
+sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai
+filesystem da montare e a quelli correntemente montati. Le funzioni servono a
+leggere il contenuto di questi file in opportune strutture \structd{fstab} e
+\structd{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e
+rimuovere le voci presenti nel file.
+
+In generale si dovrebbero usare queste funzioni, in particolare quelle
+relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
+effettua il montaggio di un filesystem. In realtà in questi casi è molto più
+semplice invocare direttamente il programma \cmd{mount}. Inoltre l'uso stesso
+di \conffile{/etc/mtab} è considerato una pratica obsoleta, in quanto se non
+aggiornato correttamente (cosa che è impossibile se la radice è montata in
+sola lettura) il suo contenuto diventa fuorviante.
+
+Per questo motivo il suo utilizzo viene deprecato ed in molti casi viene già
+oggi sostituito da un collegamento simbolico a \procfile{/proc/mounts}, che
+contiene una versione degli stessi contenuti (vale a dire l'elenco dei
+filesystem montati) generata direttamente dal kernel, e quindi sempre
+disponibile e sempre aggiornata. Per questo motivo tralasceremo la
+trattazione, di queste funzioni, rimandando al manuale della \acr{glibc}
+\cite{GlibcMan} per la documentazione completa.
+
+\conffileend{/etc/mtab}
+
+% TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
+% TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...)
+
+% TODO con il 5.2 è stata introdotta una serie di nuove syscall per montare un
+% filesystem, vedi https://lwn.net/Articles/759499/ e
+% https://git.kernel.org/linus/f1b5618e013a
+
+
+\section{La gestione di file e directory}
+\label{sec:file_dir}
+
+In questa sezione esamineremo le funzioni usate per la manipolazione dei nomi
+file e directory, per la creazione di collegamenti simbolici e diretti, per la
+gestione e la lettura delle directory. In particolare ci soffermeremo sulle
+conseguenze che derivano dalla architettura di un filesystem unix-like
+illustrata in sez.~\ref{sec:file_filesystem} per quanto attiene il
+comportamento e gli effetti delle varie funzioni. Tratteremo infine la
+directory di lavoro e le funzioni per la gestione di file speciali e
+temporanei.
+
+
+\subsection{La gestione dei nomi dei file}
+\label{sec:link_symlink_rename}
+
+% \subsection{Le funzioni \func{link} e \func{unlink}}
+% \label{sec:file_link}
+
+Una caratteristica comune a diversi sistemi operativi è quella di poter creare
+dei nomi alternativi, come gli alias del vecchio MacOS o i collegamenti di
+Windows o i nomi logici del VMS, che permettono di fare riferimento allo
+stesso file chiamandolo con nomi diversi o accedendovi da directory diverse.
+Questo è possibile anche in ambiente Unix, dove un nome alternativo viene
+usualmente chiamato ``\textsl{collegamento}'' (o \textit{link}). Data
+l'architettura del sistema riguardo la gestione dei file vedremo però che ci
+sono due metodi sostanzialmente diversi per fare questa operazione.
+
+\itindbeg{hard~link}
+\index{collegamento!diretto|(}
+
+In sez.~\ref{sec:file_filesystem} abbiamo spiegato come la capacità di
+chiamare un file con nomi diversi sia connaturata con l'architettura di un
+filesystem per un sistema Unix, in quanto il nome del file che si trova in una
+directory è solo un'etichetta associata ad un puntatore che permette di
+ottenere il riferimento ad un \textit{inode}, e che è quest'ultimo che viene
+usato dal kernel per identificare univocamente gli oggetti sul filesystem.
+
+Questo significa che fintanto che si resta sullo stesso filesystem la
+realizzazione di un \textit{link} è immediata: uno stesso file può avere tanti
+nomi diversi, dati da altrettante associazioni diverse allo stesso
+\textit{inode} effettuate tramite ``etichette'' diverse in directory
+diverse. Si noti anche come nessuno di questi nomi possa assumere una
+particolare preferenza o originalità rispetto agli altri, in quanto tutti
+fanno comunque riferimento allo stesso \textit{inode} e quindi tutti
+otterranno lo stesso file.
+
+Quando si vuole aggiungere ad una directory una voce che faccia riferimento ad
+un file già esistente come appena descritto, per ottenere quello che viene
+denominato ``\textsl{collegamento diretto}'' (o \textit{hard link}), si deve
+usare la funzione di sistema \funcd{link}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int link(const char *oldpath, const char *newpath)}
+\fdesc{Crea un nuovo collegamento diretto (\textit{hard link}).}
+}
+{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{EEXIST}] un file (o una directory) di nome \param{newpath}
+ esiste già.
+ \item[\errcode{EMLINK}] ci sono troppi collegamenti al file \param{oldpath}
+ (il numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
+ sez.~\ref{sec:sys_limits}).
+ \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
+ \param{newpath} non supporta i collegamenti diretti, è una directory o per
+ \param{oldpath} non si rispettano i criteri per i \textit{protected
+ hardlink}.\footnotemark
+ \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
+ riferimento ad un filesystem montato sullo stesso
+ \textit{mount point}.
+ \end{errlist} ed inoltre \errval{EACCES}, \errval{EDQUOT}, \errval{EFAULT},
+ \errval{EIO}, \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{ENOMEM}, \errval{ENOSPC}, \errval{ENOTDIR}, \errval{EROFS} nel loro
+ significato generico.}
+\end{funcproto}
+
+\footnotetext{i \textit{protected hardlink} sono una funzionalità di
+ protezione introdotta con il kernel 3.16 (si veda
+ sez.~\ref{sec:procadv_security_misc} per i dettagli) che limita la capacità
+ di creare un \textit{hard link} ad un file qualunque.}
+
+La funzione crea in \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 la voce
+specificata da \param{newpath} nella directory corrispondente e l'unica
+proprietà del file che verrà modificata sarà il numero di riferimenti al file
+(il campo \var{i\_nlink} della struttura \kstruct{inode}, vedi
+fig.~\ref{fig:kstruct_inode}) che verrà aumentato di uno. In questo modo lo
+stesso file potrà essere acceduto sia con \param{newpath} che
+con \param{oldpath}.
+
+Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
+collegamento diretto è possibile solo se entrambi i \textit{pathname} sono
+nello stesso filesystem ed inoltre esso deve supportare gli \textit{hard link}
+(il meccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di
+Windows). In realtà la funzione ha un ulteriore requisito, e cioè che non solo
+che i due file siano sullo stesso filesystem, ma anche che si faccia
+riferimento ad essi all'interno dello stesso \textit{mount point}.\footnote{si
+ tenga presente infatti, come detto in sez.~\ref{sec:filesystem_mounting},
+ che a partire dal kernel 2.4 uno stesso filesystem può essere montato più
+ volte su directory diverse.}
+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 fig.~\ref{fig:file_link_loop})
+la cui rimozione diventerebbe piuttosto complicata.\footnote{occorrerebbe
+ infatti eseguire il programma \cmd{fsck} per riparare il filesystem, perché
+ in caso di \textit{loop} la directory non potrebbe essere più svuotata,
+ contenendo comunque se stessa, e quindi non potrebbe essere rimossa.}
+
+Data la pericolosità di questa operazione, e visto che i collegamenti
+simbolici (che tratteremo a breve) ed i \textit{bind mount} (già visti in
+sez.~\ref{sec:filesystem_mounting}) possono fornire la stessa funzionalità
+senza questi problemi, nel caso di Linux questa capacità è stata completamente
+disabilitata, e al tentativo di creare un collegamento diretto ad una
+directory la funzione \func{link} restituisce sempre l'errore \errcode{EPERM}.
+
+Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
+\textit{hard link} ad un collegamento simbolico. In questo caso lo standard
+POSIX.1-2001 prevederebbe che quest'ultimo venga risolto e che il collegamento
+sia effettuato rispetto al file cui esso punta, e che venga riportato un
+errore qualora questo non esista o non sia un file. Questo era anche il
+comportamento iniziale di Linux ma a partire dai kernel della serie
+2.0.x\footnote{per la precisione il comportamento era quello previsto dallo
+ standard POSIX fino al kernel di sviluppo 1.3.56, ed è stato temporaneamente
+ ripristinato anche durante lo sviluppo della serie 2.1.x, per poi tornare al
+ comportamento attuale fino ad oggi (per riferimento si veda
+ \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento
+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
+\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 è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int symlink(const char *oldpath, const char *newpath)}
+\fdesc{Crea un nuovo collegamento simbolico (\textit{symbolic link}).}
+}
+{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{EACCES}] o non si hanno i permessi sulla directory in cui
+ creare il \textit{link}.
+ \item[\errcode{EEXIST}] esiste già un file \param{newpath}.