dovrà creare anche la relativa versione della funzione \code{mount}.
\itindbeg{pathname}
+\itindbeg{pathname~resolution}
Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount}
della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry}
-iniziale nel \itindex{mount~point} \textit{mount point} dello stesso si avrà
+iniziale nel \itindex{mount~point} \textit{mount point} dello stesso, si avrà
comunque un punto di partenza. Inoltre essendo questa \textit{dentry} relativa
a quel tipo di filesystem essa farà riferimento ad un \textit{inode} di quel
filesystem, e come vedremo questo farà sì che venga eseguita una
filesystem.
\itindend{pathname}
+\itindend{pathname~resolution}
% Un secondo effetto della chiamata funzione \texttt{mount} di
% \kstruct{file\_system\_type} è quello di allocare una struttura
funzione \texttt{open} che invece è citata in
tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
invocata dato che nella struttura \kstruct{inode} è presente anche il
- puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
- fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un
-file richiede comunque un'altra operazione che mette in gioco l'omonimo
-oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che
-viene associata ad ogni file aperto nel sistema.
+ puntatore \var{i\_fop} alla struttura \kstruct{file\_operation} che fornisce
+ detta funzione.} Questo avviene perché su Linux l'apertura di un file
+richiede comunque un'altra operazione che mette in gioco l'omonimo oggetto del
+VFS: l'allocazione di una struttura di tipo \kstruct{file} che viene associata
+ad ogni file aperto nel sistema.
I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
dei file descriptor il cui significato emergerà più avanti, il puntatore
-\struct{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga
-per i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
+\var{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga per
+i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
fornite dal VFS per i file. Si sono riportate in
tab.~\ref{tab:file_file_operations} le più significative.
che contiene riferimenti ad \textit{inode} relativi ad altri filesystem.
Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una
nuova voce per un file esistente con la funzione \func{link} (vedi
- sez.~\ref{sec:file_link}) a file nel filesystem corrente.
+ sez.~\ref{sec:file_link}), a operare su file nel filesystem corrente.
\item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
del file non viene spostato fisicamente, viene semplicemente creata una
di più è la famiglia di filesystem evolutasi a partire dal \textit{second
extended filesystem}, o \acr{ext2}. Il filesystem \acr{ext2} ha subito un
grande sviluppo e diverse evoluzioni, fra cui l'aggiunta del
-\textit{journaling} con \acr{ext3}, probabilmente ancora il filesystem più
-diffuso, ed una serie di ulteriori miglioramento con il successivo \acr{ext4},
-che sta iniziando a sostituirlo gradualmente. In futuro è previsto che questo
-debba essere sostituito da un filesystem completamente diverso, \acr{btrfs},
-che dovrebbe diventare il filesystem standard di Linux, ma questo al momento è
-ancora in fase di sviluppo.\footnote{si fa riferimento al momento dell'ultima
- revisione di di questo paragrafo, l'inizio del 2012.}
+\textit{journaling} con il passaggio ad \acr{ext3}, che probabilmente è ancora
+il filesystem più diffuso, ed una serie di ulteriori miglioramenti con il
+successivo \acr{ext4}, che sta iniziando a sostituirlo gradualmente. In futuro
+è previsto che questo debba essere sostituito da un filesystem completamente
+diverso, \acr{btrfs}, che dovrebbe diventare il filesystem standard di Linux,
+ma questo al momento è ancora in fase di sviluppo.\footnote{si fa riferimento
+ al momento dell'ultima revisione di di questo paragrafo, l'inizio del 2012.}
Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
dalle prime versioni del kernel e supporta tutte le caratteristiche di un
illustrato, ottenendo un forte guadagno di prestazioni in caso di directory
contenenti un gran numero di file.
-% TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si
-% possono incontrare (in particolare quelle relative alla perdita di contenuti
-% in caso di crash del sistema)
+% TODO (bassa priorità) portare a ext3, ext4 e btrfs ed illustrare le
+% problematiche che si possono incontrare (in particolare quelle relative alla
+% perdita di contenuti in caso di crash del sistema)
+% TODO (media priorità) trattare btrfs quando sarà usato come stabile
\subsection{La gestione dell'uso dei filesystem}
\label{sec:sys_file_config}
Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file
-occorre prima rendere disponibile al sistema il filesystem su cui essi sono
-memorizzati; l'operazione di attivazione del filesystem è chiamata
-\textsl{montaggio}, per far questo in Linux si usa la funzione \funcd{mount},
+occorre rendere disponibile al sistema il filesystem su cui essi sono
+memorizzati. L'operazione di attivazione del filesystem è chiamata
+\textsl{montaggio} e per far questo in Linux si usa la funzione \funcd{mount},
il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che
usa la omonima \textit{system call} e non è portabile.}
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
- componenti del \itindex{pathname} \textit{pathname}, o si è cercato di
- montare un filesystem disponibile in sola lettura senza aver specificato
- \const{MS\_RDONLY} o il device \param{source} è su un filesystem montato
- con l'opzione \const{MS\_NODEV}.
+ componenti del \textit{pathname}, o si è cercato di montare un filesystem
+ disponibile in sola lettura senza aver specificato \const{MS\_RDONLY} o il
+ device \param{source} è su un filesystem montato con l'opzione
+ \const{MS\_NODEV}.
\item[\errcode{EBUSY}] \param{source} è già montato, o non può essere
rimontato in sola lettura perché ci sono ancora file aperti in scrittura,
o non può essere montato su \param{target} perché la directory è ancora in
\textit{mount point} o è la radice.
\item[\errcode{ELOOP}] si è cercato di spostare un \itindex{mount~point}
\textit{mount point} su una sottodirectory di \param{source} o si sono
- incontrati troppi link simolici nella risoluzione di un nome.
+ incontrati troppi link simbolici nella risoluzione di un nome.
\item[\errcode{EMFILE}] in caso di filesystem virtuale, la tabella dei
dispositivi fittizi (chiamati \textit{dummy} nella documentazione inglese)
è piena.
di dispositivo indicato da \param{source}. In entrambi i casi, come daremo per
assunto da qui in avanti tutte le volte che si parla di directory o file nel
passaggio di un argomento di una funzione, si intende che questi devono essere
-indicati con la stringa contenente il loro \itindex{pathname}
-\textit{pathname}.
+indicati con la stringa contenente il loro \textit{pathname}.
Normalmente un filesystem è contenuto su un disco o una partizione, ma come
illustrato in sez.~\ref{sec:file_vfs_work} la struttura del
disponibile nella directory specificata come \itindex{mount~point}
\textit{mount point}, il precedente contenuto di detta directory viene
mascherato dal contenuto della directory radice del filesystem montato. Fino
-ai kernel della serie 2.2.x non era possibile montare un filesytem se un
+ai kernel della serie 2.2.x non era possibile montare un filesystem se un
\textit{mount point} era già in uso.
A partire dal kernel 2.4.x inoltre è divenuto possibile sia spostare
esistono pure alcune opzioni che si possono applicare in generale, anche se
non è detto che tutti i filesystem le supportino, che si specificano tramite
l'argomento \param{mountflags}. L'argomento inoltre può essere utilizzato per
-modificare il comportamento della funzione, facendole compiere una operazione
-diversa (ad esempio un rimontaggio, invece che un montaggio).
+modificare il comportamento della funzione \func{mount}, facendole compiere
+una operazione diversa (ad esempio un rimontaggio, invece che un montaggio).
In Linux \param{mountflags} deve essere un intero a 32 bit; fino ai kernel
della serie 2.2.x i 16 più significativi avevano un valore riservato che
possibile montare una directory di un filesystem in un'altra directory,
l'opzione è disponibile a partire dai kernel della serie 2.4. In questo caso
verranno presi in considerazione solo gli argomenti \param{source}, che
- stavolta indicherà la directory che si vuole montare (e non un file di
- dispositivo) e \param{target} che indicherà la directory su cui verrà
+ stavolta indicherà la directory che si vuole montare e non un file di
+ dispositivo, e \param{target} che indicherà la directory su cui verrà
effettuato il \textit{bind mount}. Gli argomenti \param{filesystemtype}
e \param{data} vengono ignorati.
- In sostanza quello che avviene è che in corrispondenza del \index{pathname}
- \textit{pathname} indicato da \param{target} viene montato l'\textit{inode}
- di \param{source}, così che la porzione di albero dei file presente sotto
+ In sostanza quello che avviene è che in corrispondenza del \textit{pathname}
+ indicato da \param{target} viene montato l'\textit{inode} di \param{source},
+ così che la porzione di albero dei file presente sotto
\param{source} diventi visibile allo stesso modo sotto
\param{target}. Trattandosi esattamente dei dati dello stesso filesystem,
ogni modifica fatta in uno qualunque dei due rami di albero sarà visibile
Dal punto di vista del \itindex{Virtual~File~System} VFS l'operazione è
analoga al montaggio di un filesystem proprio nel fatto che anche in questo
- caso si inserisce in corripondenza della \textit{dentry} di \texttt{target}
+ caso si inserisce in corrispondenza della \textit{dentry} di \texttt{target}
un diverso \textit{inode}, che stavolta, invece di essere quello della
radice del filesystem indicato da un file di dispositivo, è quello di una
directory già montata.
Fino al kernel 2.6.26 questo flag doveva essere usato da solo, in quanto il
\textit{bind mount} continuava ad utilizzare le stesse opzioni del montaggio
originale, dal 2.6.26 è stato introdotto il supporto per il cosiddetto
- \textit{read-only bind mount} e viene onorata la presenza del flag
- \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file sotto
- \param{target} sia effettuabile esclusivamente in sola lettura.
+ \textit{read-only bind mount} e viene onorata la presenza aggiuntiva del
+ flag \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file
+ sotto \param{target} sia effettuabile esclusivamente in sola lettura.
Il supporto per il \textit{bind mount} consente di superare i limiti
presenti per gli \textit{hard link} (di cui parleremo in
- sez.~\ref{sec:file_link}) ottenendo un qualcosa di analogo in cui si può
- fare riferimento alla porzione dell'albero dei file di un filesystem
- presente a partire da una certa directory utilizzando una qualunque altra
- directory, anche se questa sta su un filesystem diverso. Si può così fornire
- una alternativa all'uso dei link simbolici (di cui parleremo in
- sez.~\ref{sec:file_symlink}) che funziona correttamente anche all'intero di
- un \textit{chroot} (argomento su cui torneremo in
- sez.~\ref{sec:file_chroot}.
+ sez.~\ref{sec:file_link}) con la possibilità di fare riferimento alla
+ porzione dell'albero dei file di un filesystem presente a partire da una
+ certa directory, utilizzando una qualunque altra directory, anche se questa
+ sta su un filesystem diverso. Si può così fornire una alternativa all'uso
+ dei link simbolici (di cui parleremo in sez.~\ref{sec:file_symlink}) che
+ funziona correttamente anche all'intero di un \textit{chroot} (argomento su
+ cui torneremo in sez.~\ref{sec:file_chroot}).
\itindend{bind~mount}
\item[\const{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
(introdotta a partire dai kernel della serie 2.6). L'opzione si applica a
tutte le directory del filesystem, ma su alcuni filesystem è possibile
impostarla a livello di singole directory o per i sottorami di una directory
- con il comando \cmd{lsattr}.\footnote{questo avviene tramite delle opportune
+ con il comando \cmd{chattr}.\footnote{questo avviene tramite delle opportune
\texttt{ioctl} (vedi sez.~\ref{sec:file_ioctl}).}
Questo consente di ridurre al minimo il rischio di perdita dei dati delle
vengono ignorati.
Lo spostamento avviene atomicamente, ed il ramo di albero presente
- sotto \param{source} sarà immediatamante visibile sotto \param{target}. Non
+ sotto \param{source} sarà immediatamente visibile sotto \param{target}. Non
esiste cioè nessun momento in cui il filesystem non risulti montato in una o
nell'altra directory e pertanto è garantito che la risoluzione di
- \textit{pathname} relativi all'interno del filesystem non possa fallire.
+ \itindsub{pathname}{relativo} \textit{pathname} relativi all'interno del
+ filesystem non possa fallire.
\item[\const{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
degli \textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
\textit{access time} sul filesystem soltanto quando questo risulti
- antecendente il valore corrente del \textit{modification time} o del
+ antecedente il valore corrente del \textit{modification time} o del
\textit{change time} (per i tempi dei file si veda
sez.~\ref{sec:file_file_times}). L'opzione è disponibile a partire dal
kernel 2.6.20, mentre dal 2.6.30 questo è diventato il comportamento di
cambiandone le opzioni di montaggio in maniera atomica. In questo modo si
possono modificare le opzioni del filesystem anche se questo è in uso. Gli
argomenti \param{source} e \param{target} devono essere gli stessi usati per
- il montaggio originale, mentre \param{data} che \param{mountflags}
+ il montaggio originale, mentre sia \param{data} che \param{mountflags}
conterranno le nuove opzioni, \param{filesystemtype} viene ignorato.
Qualunque opzione specifica del filesystem indicata con \param{data} può
point} che si intende marcare, e tutti gli altri argomenti verranno
ignorati.
- Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
- effettuati da un \textit{mount point} marcato da essa siano di tipo
- \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
- ogni ulteriore operazione di montaggio o smontaggio che avviene su una
- directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
- smontaggio cioè vengono ``\textsl{propagate}'' a tutti i \textit{mount
- point} della stessa condivisione, e la sezione di albero di file vista al
- di sotto di ciascuno di essi sarà sempre identica.
+ Lo scopo dell'opzione è ottenere che tutti i successivi \itindex{bind~mount}
+ \textit{bind mount} effettuati da un \textit{mount point} marcato da essa
+ siano di tipo \textit{shared}, cioè ``\textsl{condividano}'' con l'originale
+ e fra di loro ogni ulteriore operazione di montaggio o smontaggio che
+ avviene su una directory al di sotto di uno qualunque di essi. Le operazioni
+ di montaggio e smontaggio effettuate al di sotto di un qualunque
+ \textit{mount point} così marcato verranno ``\textsl{propagate}'' a tutti i
+ \itindex{mount~point} \textit{mount point} della stessa condivisione, e la
+ sezione di albero di file vista al di sotto di ciascuno di essi sarà sempre
+ identica.
\item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
effettuati da un \textit{mount point} marcato da essa siano di tipo
\textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di
montaggio o smontaggio che avviene su una directory al di sotto del
- \textit{mount point} originale. Le operazioni di montaggio e smontaggio in
+ \textit{mount point} originale. Le operazioni di montaggio e smontaggio in
questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
essi potranno eseguire al loro interno ulteriori montaggi che non saranno
\param{target} dovrà fare riferimento al \textit{mount point} che si intende
marcare, e tutti gli altri argomenti verranno ignorati.
- Un \textit{mount point} marcato in questo modo disabilità la capacità di
- eseguire dei \itindex{bind~mount} \textit{bind mount}. Si comporta cioè come
- allo stesso modo di un \itindex{mount~point} \textit{mount point} ordinario
- di tipo \textit{private} con in più la restrizione che nessuna sua
- sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere
- utilizzata per un come sorgente di un \itindex{bind~mount} \textit{bind
- mount}.
+ Un \textit{mount point} marcato in questo modo disabilita la capacità di
+ eseguire dei \itindex{bind~mount} \textit{bind mount} del suo contenuto. Si
+ comporta cioè come allo stesso modo di un \itindex{mount~point}
+ \textit{mount point} ordinario di tipo \textit{private} con in più la
+ restrizione che nessuna sua sottodirectory (anche se relativa ad un
+ ulteriore montaggio) possa essere utilizzata per un come sorgente di un
+ \itindex{bind~mount} \textit{bind mount}.
\end{basedescript}
Una volta che non si voglia più utilizzare un certo filesystem è possibile
-\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
+``\textsl{smontarlo}'' usando la funzione \funcd{umount}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/mount.h}
\fdecl{umount(const char *target)}
\fdesc{Smonta un filesystem.}
}
-{La funzione ritorna $0$ in caso
- di successo e $-1$ per un errore,
+{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{EPERM}] il processo non ha i privilegi di amministratore.
- \item[\errcode{EBUSY}] \param{target} è la \index{directory~di~lavoro}
- directory di lavoro di qualche processo, o contiene dei file aperti, o un
- altro mount point.
-\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
-\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro
- significato generico.}
+ \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 \itindex{capabilities} capacità
+ \texttt{CAP\_SYS\_ADMIN}.}
+
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
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 \itindex{mount~point} \textit{mount point} viene smontato quello
-che è stato montato per ultimo.
+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 \index{directory~di~lavoro}
+directory di lavoro di un qualunque processo o il \itindex{mount~point}
+\textit{mount point} di un altro filesystem.
-Si tenga presente che la funzione fallisce quando il filesystem è
-\textsl{occupato}, cioè quando ci sono ancora dei file aperti sul filesystem,
-se questo contiene la \index{directory~di~lavoro} directory di lavoro corrente
-di un qualunque processo o il \itindex{mount~point} \textit{mount point} di un
-altro filesystem; in questo caso l'errore restituito è \errcode{EBUSY}.
+Linux provvede inoltre una seconda funzione, \funcd{umount2}, che consente un
+maggior controllo delle operazioni, come forzare lo smontaggio di un
+filesystem anche quando questo risulti occupato; il suo prototipo è:
-Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni
-casi permette di 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 è identica a \func{umount} per valori di ritorno e codici di
- errore. }
+{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{BUSY}] \param{target} è la \index{directory~di~lavoro}
+ directory di lavoro di qualche processo, o contiene dei file aperti, o un
+ altro mount point.
+ \item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
+ ed il filesystem non era occupato.
+ \item[\errcode{EINVAL}] \param{target} non è un \itindex{mount~point}
+ \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, e al momento l'unico valore
-definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli.
-Specificando \const{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.
+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
+\const{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 \itindex{mount~point}
+ \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
+ link simbolico (vedi sez.~\ref{sec:file_symlink})
+ 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 \const{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 \const{MNT\_EXPIRE}, che non può essere specificato insieme agli altri
+due, si marca il \itindex{mount~point} \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{BUSY}. 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 \const{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se
+questo è un link simbolico (vedi sez.~\ref{sec:file_symlink}). 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
+FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
+ interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
+ di implementare le funzioni del \textit{Virtual File System} in user space,
+ così da rendere possibile agli utenti l'implementazione di un loro filesytem
+ qualunque (con applicazioni di grande interesse come il filesystem cifrato
+ \textit{encfs} o il filesystem di rete \textit{sshfs}).} 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 link simbolici che puntano ad altri \textit{mount point},
+ottenendo così la possibilità di smontare qualunque filesystem.
-% TODO documentare MNT_DETACH e MNT_EXPIRE ...
Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD,
ma con una struttura diversa.} utili per ottenere in maniera diretta
{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
+ \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; queste 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.
+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
\label{fig:sys_statfs}
\end{figure}
-
Le \acr{glibc} provvedono infine una serie di funzioni per la gestione dei due
file \conffile{/etc/fstab} ed \conffile{/etc/mtab}, 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 \struct{fstab} e \struct{mntent}, e, per
-\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}, per cui ne
-tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
-\cite{glibc} per la documentazione completa.
-
-% TODO scrivere relativamente alle varie funzioni (getfsent e getmntent &C)
-% TODO documentare swapon e swapoff (man 2 ...)
-
-
-
-
+opportune strutture \struct{fstab} e \struct{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.
+
+Pe questo motivo il suo utilizzo viene deprecato ed in molti casi viene già
+oggi sostituito da un link 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 delle \acr{glibc} \cite{glibc} per la
+documentazione completa.
+
+% TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
+% TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...)
\section{La gestione di file e directory}
\label{sec:file_dir}
la gestione dei file ha delle caratteristiche specifiche che derivano
direttamente dall'architettura del sistema. In questa sezione esamineremo le
funzioni usate per la manipolazione di file e directory, per la creazione di
-link simbolici e diretti, per la gestione e la lettura delle directory.
-
-In particolare ci soffermeremo sulle conseguenze che derivano
-dall'architettura dei filesystem illustrata nel capitolo precedente per quanto
-riguarda il comportamento e gli effetti delle varie funzioni.
+link simbolici e diretti, per la gestione e la lettura delle directory. In
+particolare ci soffermeremo sulle conseguenze che derivano dalla struttura
+generica di un qualunque filesystem illustrata in
+sez.~\ref{sec:file_filesystem} per quanto attiene il comportamento e gli
+effetti delle varie funzioni.
\subsection{Le funzioni \func{link} e \func{unlink}}
chiamandolo con nomi diversi o accedendovi da directory diverse.
Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
-usualmente chiamati \textit{link}; ma data l'architettura del sistema riguardo
-la gestione dei file ci sono due metodi sostanzialmente diversi per fare
-questa operazione.
+usualmente chiamati ``\textit{link}''; ma data l'architettura del sistema
+riguardo la gestione dei file ci sono due metodi sostanzialmente diversi per
+fare questa operazione.
Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un
file su disco avviene passando attraverso il suo \itindex{inode}
della directory, che viene associata ad un puntatore che fa riferimento al
suddetto \textit{inode}.
-Questo significa che, fintanto che si resta sullo stesso filesystem, la
-realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi
+Questo significa che fintanto che si resta sullo stesso filesystem la
+realizzazione di un link è immediata ed uno stesso file può avere tanti nomi
diversi, dati da altrettante associazioni diverse allo stesso \itindex{inode}
-\textit{inode} effettuate tramite ``etichette'' diverse in directory
-diverse. Si noti anche che nessuno di questi nomi viene ad assumere una
-particolare preferenza o originalità rispetto agli altri, in quanto tutti
-fanno comunque riferimento allo stesso \itindex{inode} \textit{inode}.
+\textit{inode} effettuate tramite ``etichette'' diverse (voci, nella
+nomenclatura di sez.~\ref{sec:file_filesystem}) in directory diverse. Si noti
+anche che nessuno di questi nomi viene ad assumere una particolare preferenza
+o originalità rispetto agli altri, in quanto tutti fanno comunque riferimento
+allo stesso \itindex{inode} \textit{inode}.
Per aggiungere ad una directory una voce che faccia riferimento ad un
\itindex{inode} \textit{inode} già esistente si utilizza la funzione
-\func{link}; si suole chiamare questo tipo di associazione un collegamento
-diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:
-\begin{prototype}{unistd.h}
-{int link(const char *oldpath, const char *newpath)}
- Crea un nuovo collegamento diretto.
-
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore nel qual caso \var{errno} viene impostata ai valori:
+\funcd{link}, e si suole chiamare questo tipo di associazione un collegamento
+diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:
+
+\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{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
- riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
- \textit{mount point}.
- \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
- \param{newpath} non supporta i link diretti o è una directory.
\item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
esiste già.
\item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il
numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
sez.~\ref{sec:sys_limits}).
- \end{errlist}
- ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOTDIR},
- \errval{EFAULT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP},
- \errval{ENOSPC}, \errval{EIO}.}
-\end{prototype}
+ \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
+ \param{newpath} non supporta i link diretti o è una directory.
+ \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
+ riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
+ \textit{mount point}.
+ \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
+ \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
+ \errval{ENOSPC}, \errval{ENOTDIR}, \errval{EROFS} nel loro significato
+ generico.}
+\end{funcproto}
-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.
+
+La funzione crea sul \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. In questo modo lo stesso file può essere 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). 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 sullo stesso
-\itindex{mount~point} \textit{mount point}.\footnote{si tenga presente infatti
- (vedi sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno
- stesso filesystem può essere montato più volte su directory diverse.}
+collegamento diretto è possibile solo se entrambi i \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). 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 sullo stesso \itindex{mount~point} \textit{mount
+ point}.\footnote{si tenga presente infatti (vedi
+ sez.~\ref{sec:sys_file_config}) 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 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
+sez.~\ref{sec:file_symlink}, dove riprenderemo il discorso) che molti
+programmi non sono in grado di gestire e la cui rimozione diventerebbe
+piuttosto complicata (in genere per questo tipo di errori occorre eseguire il
programma \cmd{fsck} per riparare il filesystem).
Data la pericolosità di questa operazione e la disponibilità dei link
funzione \func{link} restituisce l'errore \errcode{EPERM}.
Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
-\textit{hard link} ad un link simbolico. In questo caso lo standard POSIX
-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
+\textit{hard link} ad un link 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
-rispetto al link simbolico, e non al file cui questo punta.
+rispetto al link simbolico, e non al file cui questo punta. La revisione
+POSIX.1-2008 lascia invece il comportamento dipendente dall'implementazione,
+cosa che rende Linux aderente allo standard.
-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
+La ragione di questa differenza rispetto al vecchio 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
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.}
+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.}
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{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{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},
+ \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{ENOENT},
\errval{ENOTDIR}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP},
- \errval{EIO}.}
-\end{prototype}
+ \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}).
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}
+
+\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
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}
+
+\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
\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
+ \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},
+ \end{errlist} ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
\errval{ENOENT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP} e
- \errval{ENOSPC}.}
-\end{prototype}
+ \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
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{funcproto}{
+\fhead{unistd.h}
+\fdecl{int symlink(const char *oldpath, const char *newpath)}
+\fdesc{Crea un nuovo link simbolico.}
+}
+{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{EPERM}] il filesystem che contiene \param{newpath} non
supporta i link simbolici.
\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}
+ \end{errlist} ed inoltre \errval{EFAULT}, \errval{EACCES},
+ \errval{ENAMETOOLONG}, \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP},
+ \errval{ENOSPC} e \errval{EIO} nel loro significato generico.}
+\end{funcproto}
-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}.
+La funzione crea un nuovo link simbolico con \textit{pathname} \param{newpath}
+che fa riferimento ad \param{oldpath}. Si tenga presente che la funzione non
+effettua nessun controllo sull'esistenza di un file di nome \param{oldpath},
+ma si limita ad inserire il \textit{pathname} 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
\file{/boot/boot/boot} e così via.
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
-un \itindex{pathname} \textit{pathname} possano essere seguiti un numero
-limitato di link simbolici, il cui valore limite è specificato dalla costante
+un \textit{pathname} possano essere seguiti un numero limitato di link
+simbolici, il cui valore limite è specificato dalla costante
\const{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
errore ed \var{errno} viene impostata al valore \errcode{ELOOP}.
La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
standard presenti in ogni directory (cioè ``\file{.}'' e ``\file{..}''), con
il nome indicato dall'argomento \param{dirname}. Il nome può essere indicato
-sia come \itindex{pathname} \textit{pathname} assoluto che come
-\itindex{pathname} \textit{pathname} relativo.
+sia come \itindsub{pathname}{assoluto} \textit{pathname} assoluto che come
+\itindsub{pathname}{relativo} \textit{pathname} relativo.
I permessi di accesso (vedi sez.~\ref{sec:file_access_control}) con cui la
directory viene creata sono specificati dall'argomento \param{mode}, i cui
La funzione cancella la directory \param{dirname}, che deve essere vuota (la
directory deve cioè contenere soltanto le due voci standard ``\file{.}'' e
-``\file{..}''). Il nome può essere indicato con il \itindex{pathname}
-\textit{pathname} assoluto o relativo.
+``\file{..}''). Il nome può essere indicato con il \textit{pathname} assoluto
+o relativo.
La modalità con cui avviene la cancellazione è analoga a quella di
\func{unlink}: fintanto che il numero di link \itindex{inode}
stream}.
Di questa funzione esiste anche una versione \index{funzioni!rientranti}
-rientrante, \func{readdir\_r},\footnote{per usarla è necessario definire una
+rientrante, \funcd{readdir\_r},\footnote{per usarla è necessario definire una
qualunque delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
\macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
\macro{\_POSIX\_SOURCE}.} che non usa una struttura allocata staticamente, e
\struct{dirent}) come argomento della funzione di selezione specificata da
\param{filter}; se questa ritorna un valore diverso da zero il puntatore viene
inserito in un vettore che viene allocato dinamicamente con \func{malloc}.
-Qualora si specifichi un valore \val{NULL} per l'argomento \func{filter} non
+Qualora si specifichi un valore \val{NULL} per l'argomento \param{filter} non
viene fatta nessuna selezione e si ottengono tutte le voci presenti.
-Le voci selezionate possono essere riordinate tramite \func{qsort}, le modalità
-del riordinamento possono essere personalizzate usando la funzione
-\param{compar} come criterio di ordinamento di \func{qsort}, la funzione
+Le voci selezionate possono essere riordinate tramite \funcm{qsort}, le
+modalità del riordinamento possono essere personalizzate usando la funzione
+\param{compar} come criterio di ordinamento di \funcm{qsort}, la funzione
prende come argomenti le due strutture \struct{dirent} da confrontare
restituendo un valore positivo, nullo o negativo per indicarne l'ordinamento;
alla fine l'indirizzo della lista ordinata dei puntatori alle strutture
campo \var{d\_name} delle varie voci). Le \acr{glibc} prevedono come
estensione\footnote{le glibc, a partire dalla versione 2.1, effettuano anche
l'ordinamento alfabetico tenendo conto delle varie localizzazioni, usando
- \func{strcoll} al posto di \func{strcmp}.} anche \func{versionsort}, che
+ \funcm{strcoll} al posto di \funcm{strcmp}.} anche \func{versionsort}, che
ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
\texttt{file10} viene comunque dopo \texttt{file4}.)
\subsection{La directory di lavoro}
\label{sec:file_work_dir}
-\itindbeg{pathname}
\index{directory~di~lavoro|(}
+
Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
- della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
+ della sua \kstruct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
precisamente nel campo \texttt{pwd} della sotto-struttura
- \struct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
+ \kstruct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
\textsl{directory di lavoro} (in inglese \textit{current working directory}).
La directory di lavoro è quella da cui si parte quando un
\itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,
quello in cui il processo non ha il permesso di accesso alla directory
specificata da \param{fd}.
-\itindend{pathname}
\index{directory~di~lavoro|)}
\headfile{stdio.h}.}
Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
-\func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
+\funcm{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
il file esplicitamente, il suo prototipo è:
\begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
\errval{EACCES}, \errval{ENOMEM}, \errval{ENAMETOOLONG}.}
\end{functions}
-La funzione \func{stat} legge le informazioni del file il cui pathname è
-specificato dalla stringa puntata da \param{file\_name} e le inserisce nel
-buffer puntato dall'argomento \param{buf}; la funzione \func{lstat} è identica
-a \func{stat} eccetto che se \param{file\_name} è un link simbolico vengono
-lette le informazioni relative ad esso e non al file a cui fa
-riferimento. Infine \func{fstat} esegue la stessa operazione su un file già
-aperto, specificato tramite il suo file descriptor \param{filedes}.
+La funzione \func{stat} legge le informazioni del file il cui
+\textit{pathname} è specificato dalla stringa puntata da \param{file\_name} e
+le inserisce nel buffer puntato dall'argomento \param{buf}; la funzione
+\func{lstat} è identica a \func{stat} eccetto che se \param{file\_name} è un
+link simbolico vengono lette le informazioni relative ad esso e non al file a
+cui fa riferimento. Infine \func{fstat} esegue la stessa operazione su un file
+già aperto, specificato tramite il suo file descriptor \param{filedes}.
La struttura \struct{stat} usata da queste funzioni è definita nell'header
\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
Il campo \var{st\_size} di una struttura \struct{stat} contiene la dimensione
del file in byte, se si tratta di un file regolare. Nel caso di un link
-simbolico la dimensione è quella del \itindex{pathname} \textit{pathname} che
-il link stesso contiene; per le fifo questo campo è sempre nullo.
+simbolico la dimensione è quella del \textit{pathname} che il link stesso
+contiene; per le fifo questo campo è sempre nullo.
Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
per \func{truncate} si hanno:
\begin{errlist}
\item[\errcode{EACCES}] il file non ha permesso di scrittura o non si ha il
- permesso di esecuzione una delle directory del \itindex{pathname}
- \textit{pathname}.
+ permesso di esecuzione una delle directory del \textit{pathname}.
\item[\errcode{ETXTBSY}] il file è un programma in esecuzione.
\end{errlist}
ed anche \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT},
Entrambe le funzioni fan sì che la dimensione del file sia troncata ad un
valore massimo specificato da \param{length}, e si distinguono solo per il
-fatto che il file viene indicato con il pathname \param{file\_name} per
-\func{truncate} e con il file descriptor \param{fd} per \funcd{ftruncate}; se
-il file è più lungo della lunghezza specificata i dati in eccesso saranno
+fatto che il file viene indicato con il \textit{pathname} \param{file\_name}
+per \func{truncate} e con il file descriptor \param{fd} per \funcd{ftruncate};
+se il file è più lungo della lunghezza specificata i dati in eccesso saranno
perduti.
Il comportamento in caso di lunghezza inferiore non è specificato e dipende
dello standard POSIX (la POSIX.1-2008); sono state introdotte a partire dal
kernel 2.6.22, e supportate dalle \acr{glibc} a partire dalla versione
2.6.\footnote{in precedenza, a partire dal kernel 2.6.16, era stata introdotta
- la funzione \func{futimesat} seguendo una bozza della revisione dello
+ la funzione \funcm{futimesat} seguendo una bozza della revisione dello
standard poi modificata, questa funzione, sostituita da \func{utimensat}, è
stata dichiarata obsoleta, non è supportata da nessuno standard e non deve
essere più utilizzata: pertanto non la tratteremo.} La prima è
tempi con precisione maggiore, la seconda supporta invece, rispetto ad
\func{utimes}, una sintassi più complessa che, come vedremo in
sez.~\ref{sec:file_openat} consente una indicazione sicura dei
-\textit{pathname relativi} specificando la directory da usare come riferimento
-in \param{dirfd} e la possibilità di usare \param{flags} per indicare alla
-funzione di dereferenziare o meno i link simbolici; si rimanda pertanto la
-spiegazione del significato degli argomenti aggiuntivi alla trattazione
-generica delle varie funzioni che usano la stessa sintassi, effettuata in
-sez.~\ref{sec:file_openat}.
+\itindsub{pathname}{relativo} \textit{pathname relativi} specificando la
+directory da usare come riferimento in \param{dirfd} e la possibilità di
+usare \param{flags} per indicare alla funzione di dereferenziare o meno i link
+simbolici; si rimanda pertanto la spiegazione del significato degli argomenti
+aggiuntivi alla trattazione generica delle varie funzioni che usano la stessa
+sintassi, effettuata in sez.~\ref{sec:file_openat}.
\section{Il controllo di accesso ai file}
avanti.
La prima regola è che per poter accedere ad un file attraverso il suo
-\itindex{pathname} \textit{pathname} occorre il permesso di esecuzione in
-ciascuna delle directory che compongono il \textit{pathname}; lo stesso vale
-per aprire un file nella directory corrente (per la quale appunto serve il
-diritto di esecuzione).
+\textit{pathname} occorre il permesso di esecuzione in ciascuna delle
+directory che compongono il \textit{pathname}; lo stesso vale per aprire un
+file nella directory corrente (per la quale appunto serve il diritto di
+esecuzione).
Per una directory infatti il permesso di esecuzione significa che essa può
-essere attraversata nella risoluzione del \itindex{pathname}
-\textit{pathname}, ed è distinto dal permesso di lettura che invece implica
-che si può leggere il contenuto della directory.
+essere attraversata nella risoluzione del \textit{pathname}, ed è distinto dal
+permesso di lettura che invece implica che si può leggere il contenuto della
+directory.
Questo significa che se si ha il permesso di esecuzione senza permesso di
lettura si potrà lo stesso aprire un file in una directory (se si hanno i
permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
$222$ nel secondo). Per questo motivo il sistema associa ad ogni
processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
- \struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera di
-bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
+ \kstruct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera
+di bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
bit indicati nella maschera vengono infatti cancellati dai permessi quando un
nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche
sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
consentito a tutti i processi, mentre quello in scrittura solo ai processi
- con privilegi amministrativi dotati della \index{capabilities}
+ con privilegi amministrativi dotati della \itindex{capabilities}
\textit{capability} \const{CAP\_SYS\_ADMIN}.
\item[\texttt{system}] Anche l'accesso agli \textit{extended system
lettura ai processi che hanno la capacità di eseguire una ricerca sul file
(cioè hanno il permesso di lettura sulla directory che contiene il file) ed
in scrittura al proprietario del file o ai processi dotati della
- \textit{capability} \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale
- a dire una politica di accesso analoga a quella impiegata per gli ordinari
- permessi dei file.}
+ \textit{capability} \itindex{capabilities}
+ \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a
+ quella impiegata per gli ordinari permessi dei file.}
\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
per la lettura che per la scrittura, è consentito soltanto ai processi con
- privilegi amministrativi dotati della \index{capabilities}
+ privilegi amministrativi dotati della \itindex{capabilities}
\textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
utilizzare questi attributi per realizzare in user space dei meccanismi di
controllo che accedono ad informazioni non disponibili ai processi ordinari.
per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
\textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
user attributes} soltanto se si è proprietari della stessa, o si hanno i
- privilegi amministrativi della capability \index{capabilities}
+ privilegi amministrativi della capability \itindex{capabilities}
\const{CAP\_FOWNER}.
\end{basedescript}
\end{functions}
Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
-un pathname che indica il file di cui si vuole richiedere un attributo, la
-sola differenza è che la seconda, se il pathname indica un link simbolico,
-restituisce gli attributi di quest'ultimo e non quelli del file a cui esso fa
-riferimento. La funzione \func{fgetxattr} prende invece come primo argomento
-un numero di file descriptor, e richiede gli attributi del file ad esso
-associato.
+un \textit{pathname} che indica il file di cui si vuole richiedere un
+attributo, la sola differenza è che la seconda, se il \textit{pathname} indica
+un link simbolico, restituisce gli attributi di quest'ultimo e non quelli del
+file a cui esso fa riferimento. La funzione \func{fgetxattr} prende invece
+come primo argomento un numero di file descriptor, e richiede gli attributi
+del file ad esso associato.
Tutte e tre le funzioni richiedono di specificare nell'argomento \param{name}
il nome dell'attributo di cui si vuole ottenere il valore. Il nome deve essere
indicare quale dovrà essere la ACL assegnata di default nella creazione di un
file all'interno della directory stessa. Come avviene per i permessi le ACL
possono essere impostate solo del proprietario del file, o da un processo con
-la capability \index{capabilities} \const{CAP\_FOWNER}.
+la capability \itindex{capabilities} \const{CAP\_FOWNER}.
\begin{table}[htb]
\centering
Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
della ACL correntemente associata ad un file, che può essere identificato
-tramite un file descriptor usando \func{acl\_get\_fd} o con un pathname usando
-\func{acl\_get\_file}. Nel caso di quest'ultima funzione, che può richiedere
-anche la ACL relativa ad una directory, il secondo argomento \param{type}
-consente di specificare se si vuole ottenere la ACL di default o quella di
-accesso. Questo argomento deve essere di tipo \type{acl\_type\_t} e può
-assumere solo i due valori riportati in tab.~\ref{tab:acl_type}.
+tramite un file descriptor usando \func{acl\_get\_fd} o con un
+\textit{pathname} usando \func{acl\_get\_file}. Nel caso di quest'ultima
+funzione, che può richiedere anche la ACL relativa ad una directory, il
+secondo argomento \param{type} consente di specificare se si vuole ottenere la
+ACL di default o quella di accesso. Questo argomento deve essere di tipo
+\type{acl\_type\_t} e può assumere solo i due valori riportati in
+tab.~\ref{tab:acl_type}.
\begin{table}[htb]
\centering
\end{functions}
La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
-alla directory indicate dal pathname \param{path}, mentre con \param{type} si
-indica il tipo di ACL utilizzando le costanti di tab.~\ref{tab:acl_type}, ma
-si tenga presente che le ACL di default possono essere solo impostate
-qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
-successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
-unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
-ACL di default associata a \func{path}.\footnote{questo però è una estensione
- della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
- prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
- prende come unico argomento il pathname della directory di cui si vuole
- cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
- manuale.} La seconda funzione che consente di impostare una ACL è
-\funcd{acl\_set\_fd}, ed il suo prototipo è:
+alla directory indicate dal \textit{pathname} \param{path}, mentre
+con \param{type} si indica il tipo di ACL utilizzando le costanti di
+tab.~\ref{tab:acl_type}, ma si tenga presente che le ACL di default possono
+essere solo impostate qualora \param{path} indichi una directory. Inoltre
+perché la funzione abbia successo la ACL dovrà essere valida, e contenere
+tutti le voci necessarie, unica eccezione è quella in cui si specifica una ACL
+vuota per cancellare la ACL di default associata a
+\param{path}.\footnote{questo però è una estensione della implementazione delle
+ ACL di Linux, la bozza di standard POSIX.1e prevedeva l'uso della apposita
+ funzione \funcd{acl\_delete\_def\_file}, che prende come unico argomento il
+ \textit{pathname} della directory di cui si vuole cancellare l'ACL di
+ default, per i dettagli si ricorra alla pagina di manuale.} La seconda
+funzione che consente di impostare una ACL è \funcd{acl\_set\_fd}, ed il suo
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\hline
\const{Q\_QUOTAON} & Attiva l'applicazione delle quote disco per il
filesystem indicato da \param{dev}, si deve passare
- in \param{addr} il pathname al file che mantiene le
- quote, che deve esistere, e \param{id} deve indicare
- la versione del formato con uno dei valori di
- tab.~\ref{tab:quotactl_id_format}; l'operazione
- richiede i privilegi di amministratore.\\
+ in \param{addr} il \textit{pathname} al file che
+ mantiene le quote, che deve esistere, e \param{id}
+ deve indicare la versione del formato con uno dei
+ valori di tab.~\ref{tab:quotactl_id_format};
+ l'operazione richiede i privilegi di
+ amministratore.\\
\const{Q\_QUOTAOFF} & Disattiva l'applicazione delle quote disco per il
filesystem indicato da \param{dev}, \param{id}
e \param{addr} vengono ignorati; l'operazione
Alle due funzioni citate se ne aggiungono altre due che consentono di
convertire i valori delle costanti di tab.~\ref{tab:proc_capabilities} nelle
stringhe usate nelle rispettive rappresentazioni e viceversa. Le due funzioni,
-\func{cap\_to\_name} e \func{cap\_from\_name}, sono estensioni specifiche di
+\funcd{cap\_to\_name} e \funcd{cap\_from\_name}, sono estensioni specifiche di
Linux ed i rispettivi prototipi sono:
\begin{functions}
\headdecl{sys/capability.h}
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
\index{directory~di~lavoro} directory di lavoro, ha anche una directory
\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
- \var{pwd} e \var{root}) di \struct{fs\_struct}; vedi
+ \var{pwd} e \var{root}) di \kstruct{fs\_struct}; vedi
fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
alla radice dell'albero di file e directory come visto dal kernel (ed
illustrato in sez.~\ref{sec:file_pathname}), ha per il processo il significato
sia specificato per ogni processo apre allora la possibilità di modificare le
modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
cambiando questa directory, così come si fa coi
-\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la \index{directory~di~lavoro} directory
-di lavoro.
+\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la
+\index{directory~di~lavoro} directory di lavoro.
Normalmente la directory radice di un processo coincide anche con la radice
del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal
% LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP
% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I IOPRIO
% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS Virtual everything
-% LocalWords: dentry register resolution cache dcache operation llseek poll
-% LocalWords: multiplexing fsync fasync seek block superblock gapil tex img
+% LocalWords: dentry register resolution cache dcache operation llseek poll ln
+% LocalWords: multiplexing fsync fasync seek block superblock gapil tex img du
% LocalWords: second linked journaled source filesystemtype unsigned device
% LocalWords: mountflags NODEV ENXIO dummy devfs magic MGC RDONLY NOSUID MOVE
% LocalWords: NOEXEC SYNCHRONOUS REMOUNT MANDLOCK NODIRATIME umount MNT statfs
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: bind DIRSYNC lsattr Hierarchy FHS SHARED UNBINDABLE shared REC
+% LocalWords: subtree SILENT log unbindable BUSY EAGAIN EXPIRE DETACH NOFOLLOW
+% LocalWords: lazy
projects / gapil.git / blobdiff