dovrà creare anche la relativa versione della funzione \code{mount}.
\itindbeg{pathname}
-\itindbeg{pathname!resolution}
+\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}
+\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
\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.}
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.
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
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}
{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}
+ \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.
\item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
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
+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 inutilizzato
+un meccanismo che smonti automaticamente i filesystem che restano inutilizzati
per un certo periodo di tempo.
-% Infine il flag \const{UMOUNT\_NOFOLLOW} impedisce l'uso di un link simbolico
-% per \param{target} evitando così che si possano passare ai programmi che
-% effettuano lo smontaggio dei filesystem per i quali è previsto la possibilità
-% di gestione da parte degli utenti con uno programma \acr{sgid}
+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 \itindex{Virtual~File~System} VFS che
+ consente, tramite un opportuno modulo, di implementarne le funzioni in
+ \textit{user space}, così da rendere possibile l'implementazione di un
+ qualunque filesytem (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
+link simbolici che puntano ad altri \textit{mount point}, ottenendo così la
+possibilità di smontare qualunque filesystem.
+
Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD,
ma con una struttura diversa.} utili per ottenere in maniera diretta
\end{funcproto}
Queste funzioni permettono di ottenere una serie di informazioni generali
-riguardo al filesystem su cui si trova il file specificato con un ; 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
\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.
+file \conffile{/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 \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.
+
+Per 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{GlibcMan} 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:
+\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}
{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} nel loro significato
+ \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}
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
+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 \textit{pathname} sono
-nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti
+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
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
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}.)
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,
\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)}
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 è
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
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
+\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
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
projects / gapil.git / blobdiff