In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
file e directory, iniziando dalle funzioni di libreria che si usano per
copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che
-permette la manipolazione dei vari attributi di file e directory ed alla
-fine faremo una trattazione dettagliata su come è strutturato il sistema base
-di protezioni e controllo di accesso ai file e sulle funzioni che ne
-permettono la gestione. Tutto quello che riguarda invece la manipolazione del
-contenuto dei file è lasciato ai capitoli successivi.
+permette la manipolazione dei vari attributi di file e directory ed alla fine
+faremo una trattazione dettagliata su come è strutturato il sistema base di
+protezioni e controllo dell'accesso ai file e sulle funzioni che ne permettono
+la gestione. Tutto quello che riguarda invece la manipolazione del contenuto
+dei file è lasciato ai capitoli successivi.
funzioni usate per manipolazione nel filesytem di file e directory, per la
creazione di link simbolici e diretti, per la gestione e la lettura delle
directory; il tutto mettendo in evidenza le conseguenze della struttura
-standard della gestione dei file in un sistema unix-like, già accennate al
+standard della gestione dei file in un sistema unix-like, introdotta nel
capitolo precedente.
Questo significa che la realizzazione di un link è immediata in quanto uno
stesso file può avere tanti nomi diversi allo stesso tempo, dati da
altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
-questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
+questi nomi viene ad assumere una particolare preferenza o originalità
+rispetto agli altri.
Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si
suole chiamare questo tipo di associazione un collegamento diretto (o
Windows).
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
-filesystem, con l'eccezione delle directory. In alcuni versioni di unix solo
+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
+directory: questo viene fatto perché con una tale operazione è possibile
creare dei circoli nel filesystem (vedi l'esempio mostrato in
\secref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi
non sono in grado di gestire e la cui rimozione diventerebbe estremamente
Una delle caratteristiche di queste funzioni è che la creazione/rimozione
della nome dalla directory e l'incremento/decremento del numero di riferimenti
-nell'inode deve essere una operazione atomica (si veda
-\secref{sec:proc_atom_oper}), per questo entrambe queste funzioni sono
-realizzate tramite una singola system call.
+nell'inode devono essere effettuati in maniera atomica (si veda
+\secref{sec:proc_atom_oper}) senza possibili interruzioni fra le due
+operazioni, per questo entrambe queste funzioni sono realizzate tramite una
+singola system call.
Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
\macro{EISDIR}). Nel caso \var{newpath} indichi un file esistente questo viene
cancellato e rimpiazzato (atomicamente).
-Se \var{oldpath} è una directory allora \var{newpath} se esiste deve essere
+Se \var{oldpath} è una directory allora \var{newpath}, se esiste, deve essere
una directory vuota, altrimenti si avranno gli errori \macro{ENOTDIR} (se non
è una directory) o \macro{ENOTEMPTY} (se non è vuota). Chiaramente
\var{newpath} non può contenere \var{oldpath} altrimenti si avrà un errore
\var{newpath} è un link simbolico verrà cancellato come qualunque altro file.
Infine qualora \var{oldpath} e \var{newpath} siano due nomi dello stesso file
lo standard POSIX prevede che la funzione non dia errore, e non faccia nulla,
-lasciando entrambi i nomi; Linux segue questo standard, anche se come fatto
-notare dal manuale delle glibc, il comportamento più ragionevole sarebbe
-quello di cancellare \var{oldpath}.
+lasciando entrambi i nomi; Linux segue questo standard, anche se, come fatto
+notare dal manuale delle \textit{glibc}, il comportamento più ragionevole
+sarebbe quello di cancellare \var{oldpath}.
Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di
\func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
In ogni caso se \var{newpath} esiste e l'operazione fallisce per un qualche
motivo (come un crash del kernel), \func{rename} garantisce di lasciare
-presente una istanza di \var{newpath}, tuttavia nella sovrascrittura potrà
+presente una istanza di \var{newpath}. Tuttavia nella sovrascrittura potrà
esistere una finestra in cui sia \var{oldpath} che \var{newpath} fanno
riferimento allo stesso file.
Come abbiamo visto in \secref{sec:file_link} la funzione \func{link} crea
riferimenti agli inodes, pertanto può funzionare soltanto per file che
-risiedono sullo stesso filesystem e solo per un filesystem di tipo unix.
+risiedono sullo stesso filesystem e solo per un filesystem di tipo Unix.
Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto
ad una directory.
-Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
+Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
come avviene in altri sistemi operativi, dei file speciali che contengono il
semplicemente il riferimento ad un altro file (o directory). In questo modo è
-possibile effettuare link anche attraverso filesystem diversi, a file posti in
-filesystem che non supportano i link diretti, a delle directory, e anche a
+possibile effettuare link anche attraverso filesystem diversi, a file posti
+in filesystem che non supportano i link diretti, a delle directory, ed anche a
file che non esistono ancora.
Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
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: quello che viene chiamato un \textit{dangling link},
-letteralmente \textsl{link ciondolante}.
-
+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 \ntab\ si è riportato un elenco
\var{buff} o -1 per un errore, nel qual caso la variabile
\var{errno} viene settata a:
\begin{errlist}
- \item[\macro{EINVAL}] \var{file} non è un link simbolico o \var{size} non è
- positiva.
- \item[\macro{EROFS}] La directory su cui si vuole inserire il nuovo link è
- su un filesystem montato in sola lettura.
- \item[\macro{ENOSPC}] La directory o il filesystem in cui si vuole creare il
- link è piena e non c'è ulteriore spazio disponibile.
+ \item[\macro{EINVAL}] \param{path} non è un link simbolico o \param{size}
+ non è positiva.
\end{errlist}
ed inoltre \macro{ENOTDIR}, \macro{ENAMETOOLONG}, \macro{ENOENT},
\macro{EACCES}, \macro{ELOOP}, \macro{EIO}, \macro{EFAULT} e
\begin{figure}[htb]
\centering
- \includegraphics[width=5cm]{img/link_loop}
+ \includegraphics[width=7cm]{img/link_loop}
\caption{Esempio di loop nel filesystem creato con un link simbolico.}
\label{fig:file_link_loop}
\end{figure}
la struttura della directory \file{/boot}. Come si vede si è creato al suo
interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
- bootloader estremamente avanzato in grado di accedere direttamente
- attraverso vari filesystem al file da lanciare come sistema operativo) di
- vedere i file in questa directory, che è montata su una partizione separata
- (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
- visti dal sistema operativo.}.
+ bootloader in grado di leggere direttamente da vari filesystem il file da
+ lanciare come sistema operativo) di vedere i file in questa directory con lo
+ stesso path con cui verrebbero visti dal sistema operativo, anche se essi si
+ trovano, come è solito, su una partizione separata (e che \cmd{grub}
+ vedrebbe come radice).}.
Questo può causare problemi per tutti quei programmi che effettuano la
scansione di una directory senza tener conto dei link simbolici, ad esempio se
-lanciassimo un comando del tipo \cmd{grep -r linux *}, il loop nella directory
-porterebbe il comando ad esaminare \file{/boot}, \file{/boot/boot},
+lanciassimo un comando del tipo \code{grep -r linux *}, il loop nella
+directory porterebbe il comando ad esaminare \file{/boot}, \file{/boot/boot},
\file{/boot/boot/boot} e così via.
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
un pathname possano essere seguiti un numero limitato di link simbolici, il
-cui valore limite è specificato dalla costante \macro{MAXSYMLINKS}; qualora
+cui valore limite è specificato dalla costante \macro{MAXSYMLINKS}. Qualora
questo limite venga superato viene generato un errore ed \var{errno} viene
settata al valore \macro{ELOOP}.
-Un punto da tenere sempre presente è il fatto che un link simbolico può fare
-riferimento anche ad un file che non esiste; ad esempio possiamo creare un
-file temporaneo nella nostra directory con un link del tipo:
+Un punto da tenere sempre presente è che, come abbiamo accennato, un link
+simbolico può fare riferimento anche ad un file che non esiste; ad esempio
+possiamo creare un file temporaneo nella nostra directory con un link del
+tipo:
\begin{verbatim}
$ ln -s /tmp/tmp_file temporaneo
\end{verbatim}%$
$ cat temporaneo
cat: temporaneo: No such file or directory
\end{verbatim}%$
-con un errore che può sembrare sbagliato, dato che invece \cmd{ls} ci
-mostrerebbe l'esistenza di \file{temporaneo}.
+con un errore che può sembrare sbagliato, dato che una ispezione con \cmd{ls}
+ci mostrerebbe invece l'esistenza di \file{temporaneo}.
\subsection{La creazione e la cancellazione delle directory}
\macro{ENOENT}, \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP},
\macro{EROFS}.}
\end{prototype}
-
+
La funzione crea una nuova directory vuota (che contiene solo le due voci
standard \file{.} e \file{..}). I permessi di accesso (vedi la trattazione in
\secref{sec:file_access_control}) specificati da \var{mode} (i cui possibili
degli altri tipi di file, come i file di dispositivo e le fifo (i socket sono
un caso a parte, che vedremo in \secref{cha:socket_intro}).
-La manipolazione delle caratteristiche di questi filee e la loro cancellazione
+La manipolazione delle caratteristiche di questi file e la loro cancellazione
può essere effettuata con le stesse funzioni che operano sui file normali; ma
quando li si devono creare sono necessarie delle funzioni apposite. La prima
di queste funzioni è \func{mknod}, il suo prototipo è:
La funzione permette di creare un file speciale, ma si può usare anche per
creare file normali e fifo; l'argomento \param{mode} specifica il tipo di file
che si vuole creare ed i relativi permessi, secondo i valori riportati in
-\tabref{tab:file_mode_flags}, che vanno combinato come OR binario. I permessi
-sono comunque modificati nella maniera usuale dal valore di \var{umask} (si
-veda \secref{sec:file_umask}.
+\tabref{tab:file_mode_flags}, che vanno combinati con un OR binario. I
+permessi sono comunque modificati nella maniera usuale dal valore di
+\var{umask} (si veda \secref{sec:file_umask}).
Per il tipo di file può essere specificato solo uno fra: \macro{S\_IFREG} per
un file normale (che sarà creato vuoto), \macro{S\_IFBLK} per un device a
agli utenti normali.
I nuovi inode creati con \func{mknod} apparterranno al proprietario e al
-gruppo del processo che li creati, a meno che non si sia attivato il bit
+gruppo del processo che li ha creati, a meno che non si sia attivato il bit
\acr{sgid} per la directory o sia stata attivata la semantica BSD per il
filesystem (si veda \secref{sec:file_ownership}) in cui si va a creare
l'inode.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
errore, nel qual caso \var{errno} assumerà i valori \macro{EACCESS},
\macro{EEXIST}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOSPC},
- \macro{ENOTDIR} e\macro{EROFS}.}
+ \macro{ENOTDIR} e \macro{EROFS}.}
\end{functions}
\noindent come per \func{mknod} il file \param{pathname} non deve esistere
(neanche come link simbolico); al solito i permessi specificati da
perderebbe traccia di ogni passaggio attraverso eventuali link simbolici.
Per cambiare la directory di lavoro corrente si può usare la funzione
-\func{chdir} (omonima dell'analogo comando di shell) il cui nome sta appunto
-per \textit{change directory}), il suo prototipo è:
+\func{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta
+appunto per \textit{change directory}, il suo prototipo è:
\begin{prototype}{unistd.h}{int chdir(const char *pathname)}
Cambia la directory di lavoro corrente in \param{pathname}.
\subsection{I file temporanei}
\label{sec:file_temp_file}
-In molte occasioni è utile poter creare dei file temporanei; benchè la cosa
+In molte occasioni è utile poter creare dei file temporanei; benché la cosa
sembri semplice in realtà il problema è più sottile di quanto non appaia a
prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
creare il file dopo aver controllato che questo non esista, nel momento fra il
\macro{ENOMEM} qualora fallisca l'allocazione della stringa.}
\end{prototype}
-La funzione alloca con \code{malloc} la stringa in cui resituisce il nome, per
-cui è sempre rientrante, occorre però ricordarsi di disallocare il puntatore
-che restituisce. L'argomento \param{pfx} specifica un prefisso di massimo 5
-caratteri per il nome provvisorio. La funzione assegna come directory per il
-file temporaneo (verificando che esista e sia accessibili), la prima valida
-delle seguenti:
+La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
+per cui è sempre rientrante, occorre però ricordarsi di disallocare il
+puntatore che restituisce. L'argomento \param{pfx} specifica un prefisso di
+massimo 5 caratteri per il nome provvisorio. La funzione assegna come
+directory per il file temporaneo (verificando che esista e sia accessibili),
+la prima valida delle seguenti:
\begin{itemize*}
\item La variabile di ambiente \macro{TMPNAME} (non ha effetto se non è
definita o se il programma chiamante è \acr{suid} o \acr{sgid}, vedi
ed inoltre \macro{EFAULT}, \macro{EMFILE}, \macro{ENFILE}, \macro{ENOSPC},
\macro{EROFS} e \macro{EACCESS}.}
\end{prototype}
-\noindent restituisce direttamente uno stream già aperto (in modalità
-\code{r+b}, si veda \secref{sec:file_fopen}) e pronto per l'uso che viene
+\noindent essa restituisce direttamente uno stream già aperto (in modalità
+\code{r+b}, si veda \secref{sec:file_fopen}) e pronto per l'uso, che viene
automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo
standard non specifica in quale directory verrà aperto il file, ma \acr{glibc}
prima tentano con \macro{P\_tmpdir} e poi con \file{/tmp}. Questa funzione è
alle possibili \textit{race condition} date per \func{tmpnam} continuano a
valere; inoltre in alcune vecchie implementazioni il valore di usato per
sostituire le \code{XXXXXX} viene formato con il \acr{pid} del processo più
-una lettera, il che mette a disposizione solo 26 possibilità, e rende il nome
-temporaneo facile da indovinare. Per tutti questi motivi la funzione è
-deprecata e non dovrebbe mai essere usata.
+una lettera, il che mette a disposizione solo 26 possibilità diverse per il
+nome del file, e rende il nome temporaneo facile da indovinare. Per tutti
+questi motivi la funzione è deprecata e non dovrebbe mai essere usata.
contenuto di \param{template} è indefinito.
\end{errlist}}
\end{prototype}
-\noindent come per \func{mktemp} \param{template} non può essere una stringa
-costante. La funzione apre un file in lettura/scrittura con la funzione
-\func{open}, usando l'opzione \macro{O\_EXCL} (si veda
+\noindent come per \func{mktemp} anche in questo caso \param{template} non può
+essere una stringa costante. La funzione apre un file in lettura/scrittura con
+la funzione \func{open}, usando l'opzione \macro{O\_EXCL} (si veda
\secref{sec:file_open}), in questo modo al ritorno della funzione si ha la
certezza di essere i soli utenti del file. I permessi sono settati al valore
\code{0600}\footnote{questo è vero a partire dalle \acr{glibc} 2.0.7, le
\macro{ELOOP}, \macro{EFAULT}, \macro{EACCESS}, \macro{ENOMEM},
\macro{ENAMETOOLONG}.}
\end{functions}
+\noindent il loro comportamento è identico, solo che operano rispettivamente
+su un file, su un link simbolico e su un file descriptor.
-La struttura \var{stat} è definita nell'header \file{sys/stat.h} e in
-generale dipende dall'implementazione, la versione usata da Linux è mostrata
-in \nfig, così come riportata dalla man page (in realtà la definizione
-effettivamente usata nel kernel dipende dall'architettura e ha altri campi
-riservati per estensioni come tempi più precisi, o per il padding dei campi).
+La struttura \var{stat} usata da queste funzioni è definita nell'header
+\file{sys/stat.h} e in generale dipende dall'implementazione, la versione
+usata da Linux è mostrata in \nfig, così come riportata dalla man page di
+\func{stat} (in realtà la definizione effettivamente usata nel kernel dipende
+dall'architettura e ha altri campi riservati per estensioni come tempi più
+precisi, o per il padding dei campi).
\begin{figure}[!htb]
\footnotesize
\subsection{I tipi di file}
\label{sec:file_types}
-Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e
-alle directory esistono vari altri oggetti che possono stare su un filesystem;
-il tipo di file è ritornato dalla \func{stat} nel campo \var{st\_mode}
-(che è quello che contiene anche le informazioni relative ai permessi).
+Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e alle
+directory esistono vari altri oggetti che possono stare su un filesystem. Il
+tipo di file è ritornato dalla \func{stat} come maschera binaria nel campo
+\var{st\_mode} (che che contiene anche le informazioni relative ai permessi).
Dato che il valore numerico può variare a seconda delle implementazioni, lo
standard POSIX definisce un insieme di macro per verificare il tipo di files,
-queste vengono usate anche da Linux che supporta pure le estensioni per link
-simbolici e socket definite da BSD, l'elenco completo di tutte le macro è
+queste vengono usate anche da Linux che supporta pure le estensioni allo
+standard per i link simbolici e i socket definite da BSD; l'elenco completo
+delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
riportato in \ntab.
\begin{table}[htb]
\centering
\label{tab:file_type_macro}
\end{table}
-Oltre a queste macro è possibile usare direttamente il valore di
-\var{st\_mode} per ricavare il significato dei vari bit in esso memorizzati,
-per questo sempre in \file{sys/stat.h} sono definiti i flag riportati in
-\ntab:
+Oltre alle macro di \tabref{tab:file_type_macro} è possibile usare
+direttamente il valore di \var{st\_mode} per ricavare il tipo di file
+controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
+\file{sys/stat.h} sono definite le costanti numeriche riportate in \ntab.
+
+Il primo valore dell'elenco di \secref{tab:file_mode_flags} è la maschera
+binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
+file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
+possono essere usati per effettuare la selezione sul tipo di file voluto, con
+una opportuna combinazione.
+
\begin{table}[htb]
\centering
\footnotesize
\label{tab:file_mode_flags}
\end{table}
-Il primo valore definisce la maschera dei bit usati nei quali viene
-memorizzato il tipo di files, mentre gli altri possono essere usati per
-effettuare delle selezioni sul tipo di file voluto, combinando opportunamente
-i vari flag; ad esempio se si volesse controllare se un file è una directory o
-un file ordinario si potrebbe definire la condizione:
+Ad esempio se si volesse impostare una condizione che permetta di controllare
+se un file è una directory o un file ordinario si potrebbe definire la macro
+di preprocessore:
\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
#define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG))
\end{lstlisting}
poi si effettua il confronto con la combinazione di tipi scelta.
-\subsection{La dimensione dei file}
+\subsection{Le dimensioni dei file}
\label{sec:file_file_size}
-Il membro \var{st\_size} contiene la dimensione del file in byte (se il file
-è un file normale, nel caso di un link simbolico al dimensione è quella del
-pathname che contiene).
+Il membro \var{st\_size} contiene la dimensione del file in byte (se il file è
+un file normale, nel caso di un link simbolico la dimensione è quella del
+pathname che contiene).
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
Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
che corrisponda all'occupazione dello spazio su disco per via della possibile
-esistenza dei cosiddetti \textsl{buchi} (detti normalmente \textit{holes}) che
+esistenza dei cosiddetti \textit{holes} (letteralmente \textsl{buchi}) che
si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
una \func{lseek} (vedi \secref{sec:file_lseek}) oltre la sua conclusione
corrente.
-In tal caso si avranno differenti risultati a seconda del modi in cui si
+In questo caso si avranno risultati differenti a seconda del modo in cui si
calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
Un file può sempre essere troncato a zero aprendolo con il flag
\macro{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
-dimensione si possono usare le due funzioni:
+dimensione si possono usare le due funzioni \func{truncate} e
+\func{ftruncate}, i cui prototipi sono:
\begin{functions}
\headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad
\begin{tabular}[c]{|c|l|l|c|}
\hline
\textbf{Membro} & \textbf{Significato} & \textbf{Funzione}
- & \textbf{Opzione} \\
+ & \textbf{Opzione di \cmd{ls}} \\
\hline
\hline
\var{st\_atime}& ultimo accesso ai dati del file &\func{read},
\begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
\hline
\multicolumn{1}{|p{3cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} &
- \multicolumn{3}{|p{3cm}|}{\centering{File o directory di riferimento}}&
- \multicolumn{3}{|p{3cm}|}{\centering{Directory genitrice del riferimento}}
+ \multicolumn{3}{|p{3.6cm}|}{\centering{
+ \textbf{File o directory del riferimento}}}&
+ \multicolumn{3}{|p{3.6cm}|}{\centering{
+ \textbf{Directory contenente il riferimento}}}
&\multicolumn{1}{|p{3.6cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\
\cline{2-7}
\cline{2-7}
\multicolumn{1}{|p{3cm}|}{}
- &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
- &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
- &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
- &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
- &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
- &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(a)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(m)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(c)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(a)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(m)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(c)}}}
&\multicolumn{1}{|p{3cm}|}{} \\
\hline
\hline
\func{read}
&$\bullet$& & & & & & \\
\func{remove}
- & & &$\bullet$& &$\bullet$&$\bullet$& using
+ & & &$\bullet$& &$\bullet$&$\bullet$& se esegue
\func{unlink}\\ \func{remove}
- & & & & &$\bullet$&$\bullet$& using
+ & & & & &$\bullet$&$\bullet$& se esegue
\func{rmdir}\\ \func{rename}
& & &$\bullet$& &$\bullet$&$\bullet$& per entrambi
gli argomenti\\ \func{rmdir}
\end{table}
Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
-creazione del file, usato in molti altri sistemi operativi, ma che in unix non
+creazione del file, usato in molti altri sistemi operativi, ma che in Unix non
esiste. Per questo motivo quando si copia un file, a meno di preservare
esplicitamente i tempi (ad esempio con l'opzione \cmd{-p} di \cmd{cp}) esso
avrà sempre il tempo corrente come data di ultima modifica.
\subsection{I permessi per l'accesso ai file}
\label{sec:file_perm_overview}
-Il controllo di accesso ai file in unix segue un modello abbastanza semplice
+Il controllo di accesso ai file in Unix segue un modello abbastanza semplice
(ma adatto alla gran parte delle esigenze) in cui si dividono i permessi su
tre livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem
-di tipo unix, e non è detto che sia applicabile a un filesystem
+di tipo Unix, e non è detto che sia applicabile a un filesystem
qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
per il quale i permessi vengono assegnati in maniera fissa con un opzione in
- fase di montaggio}. Esistono inoltre estensioni che permettono di
+ fase di montaggio.}. Esistono inoltre estensioni che permettono di
implementare le ACL (\textit{Access Control List}) che sono un meccanismo di
controllo di accesso molto più sofisticato.
-Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
-\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
-identificatori di utenti e gruppi (\acr{uid} e \acr{gid}). Questi valori
+Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
+cosiddetto \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo
+degli identificatori di utenti e gruppi (\acr{uid} e \acr{gid}). Questi valori
sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
della struttura \var{stat} (si veda \secref{sec:file_stat}). Ad ogni file
-viene inoltre associato un insieme di permessi che sono divisi in tre classi,
+viene inoltre associato un insieme di permessi che sono divisi in tre livelli,
e cioè attribuiti rispettivamente all'utente proprietario del file, a un
qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
altri utenti.
I permessi, così come vengono presi dai comandi e dalle routine di sistema,
-sono espressi da un numero di 12 bit; di questi i nove meno significativi sono
+sono espressi da un numero a 12 bit; di questi i nove meno significativi sono
usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
esecuzione (indicati nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e
\cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti
-gli altri. I restanti tre bit (\acr{suid}, \acr{sgid}, e
-\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
-su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e
-\secref{sec:file_sticky}).
-
-Anche i permessi, come tutte le altre informazioni generali, sono tenuti per
-ciascun file nell'inode; in particolare essi sono contenuti in alcuni bit
-del campo \var{st\_mode} della struttura letta da \func{stat} (di nuovo si veda
-\secref{sec:file_stat} per i dettagli).
-
-In genere ci si riferisce a questo raggruppamento dei permessi usando le
-lettere \cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o}
-(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
-insieme si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente
-questa distinzione dato che in certi casi, mutuando la terminologia in uso nel
-VMS, si parla dei permessi base come di permessi per \textit{owner},
-\textit{group} ed \textit{all}, le cui iniziali possono dar luogo a confusione.
-Le costanti che permettono di accedere al valore numerico di questi bit nel
-campo \var{st\_mode} sono riportate in \ntab.
+gli altri. I restanti tre bit (\acr{suid}, \acr{sgid}, e \textsl{sticky})
+sono usati per indicare alcune caratteristiche più complesse del meccanismo
+del controllo di accesso su cui torneremo in seguito (in
+\secref{sec:file_suid_sgid} e \secref{sec:file_sticky}).
+
+Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
+memorizzati nell'inode; in particolare essi sono contenuti in alcuni bit del
+campo \var{st\_mode} della struttura \func{stat} (si veda
+\figref{fig:file_stat_struct}).
+
+In genere ci si riferisce ai tre livelli dei permessi usando le lettere
+\cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o} (per
+\textit{other}), inoltre se si vuole indicare tutti i raggruppamenti insieme
+si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente questa
+distinzione dato che in certi casi, mutuando la terminologia in uso nel VMS,
+si parla dei permessi base come di permessi per \textit{owner}, \textit{group}
+ed \textit{all}, le cui iniziali possono dar luogo a confusione. Le costanti
+che permettono di accedere al valore numerico di questi bit nel campo
+\var{st\_mode} sono riportate in \ntab.
\begin{table}[htb]
\centering
dati e che non c'è nessun supporto del sistema per le estensioni come parte
del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
i nomi dei file, ad esempio il codice C normalmente si mette in file con
-l'estensione \file{.c}, ma questa è, appunto, solo una convenzione.
+l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
+universale, solo una convenzione.
Per capire fino in fondo le proprietà di file e directory in un sistema
unix-like ed il comportamento delle relative funzioni di manipolazione occorre
una breve introduzione al funzionamento gestione dei file da parte del kernel
-e sugli oggetti su cui è basato un filesystem di tipo unix. In particolare
-occorre tenere presente dov'è che si situa la divisione fondamentale fra
-kernel space e user space che tracciavamo al \capref{cha:intro_unix}.
+e sugli oggetti su cui è basato un filesystem. In particolare occorre tenere
+presente dov'è che si situa la divisione fondamentale fra kernel space e user
+space che tracciavamo al \capref{cha:intro_unix}.
In questa sezione esamineremo come viene implementato l'accesso ai file in
Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
-prima le caratteristiche generali di un filesystem Unix, per poi trattare in
-maniera un po' più dettagliata il filesystem standard di Linux, l'\acr{ext2}.
+prima le caratteristiche generali di un filesystem di un sistema unix-like,
+per poi trattare in maniera un po' più dettagliata il filesystem standard di
+Linux, l'\acr{ext2}.
+% in particolare si riprenderà, approfondendolo sul piano dell'uso nelle
+% funzioni di libreria, il concetto di \textit{inode} di cui abbiamo brevemente
+% accennato le caratteristiche (dal lato dell'implementazione nel kernel) in
+% \secref{sec:file_vfs}.
-% in particolare si riprenderà, approfondendolo sul piano
-% dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui
-% abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione
-% nel kernel) in \secref{sec:file_vfs}.
-
-\subsection{Il \textit{virtual filesystem} di Linux}
+\subsection{Il \textit{Virtual Filesystem} di Linux}
\label{sec:file_vfs}
% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
% \textit{inode}, \textit{dentry}, \textit{dcache}.
In Linux il concetto di \textit{everything is a file} è stato implementato
-attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è
-l'interfaccia che il kernel rende disponibile ai programmi in user space
-attraverso la quale vengono manipolati i file; esso provvede un livello di
-indirezione che permette di collegare le operazioni di manipolazione sui file
-alle operazioni di I/O e gestisce l'organizzazione di questi ultimi nei vari
-modi in cui diversi filesystem la effettuano, permettendo la coesistenza
-di filesystem differenti all'interno dello stesso albero delle directory
+attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno
+strato intermedio che il kernel usa per accedere ai più svariati filesystem
+mantenendo la stessa interfaccia per i programmi in user space. Esso provvede
+un livello di indirezione che permette di collegare le operazioni di
+manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
+queste ultime nei vari modi in cui diversi filesystem le effettuano,
+permettendo la coesistenza di filesystem differenti all'interno dello stesso
+albero delle directory.
Quando un processo esegue una system call che opera su un file il kernel
chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
(o qualunque altro \textit{block device} che può contenere un filesystem), il
VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
-il superblock (vedi \ref{sec:file_ext2}), inizializzare tutte le
-variabili interne e restituire uno speciale descrittore dei filesystem montati
-al VFS; attraverso quest'ultimo diventa possibile accedere alle routine
-specifiche per l'uso di quel filesystem.
+il superblock (vedi \secref{sec:file_ext2}), inizializzare tutte le variabili
+interne e restituire uno speciale descrittore dei filesystem montati al VFS;
+attraverso quest'ultimo diventa possibile accedere alle routine specifiche per
+l'uso di quel filesystem.
Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
una apposita struttura che contiene vari dati come le informazioni comuni ad
ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
-usare le funzioni contenute nel filesystem descriptor per accedere alle routine
-specifiche di quel filesystem.
+usare le funzioni contenute nel \textit{filesystem descriptor} per accedere
+alle routine specifiche di quel filesystem.
Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
\subsection{Il funzionamento del VFS}
\label{sec:file_vfs_work}
-La funzione più fondamentale implementata dal VFS è la system call
-\func{open} che permette di aprire un file. Dato un pathname viene eseguita
-una ricerca dentro la \textit{directory entry cache} (in breve
-\textit{dcache}), una tabella di hash che contiene tutte le \textit{directory
- entry} (in breve \textit{dentry}) che permette di associare in maniera
-rapida ed efficiente il pathname a una specifica dentry.
+La funzione più importante implementata dal VFS è la system call \func{open}
+che permette di aprire un file. Dato un pathname viene eseguita una ricerca
+dentro la \textit{directory entry cache} (in breve \textit{dcache}), una
+tabella che contiene tutte le \textit{directory entry} (in breve
+\textit{dentry}) che permette di associare in maniera rapida ed efficiente il
+pathname a una specifica \textit{dentry}.
Una singola \textit{dentry} contiene in genere il puntatore ad un
\textit{inode}; quest'ultimo è la struttura base che sta sul disco e che
identifica un singolo oggetto del VFS sia esso un file ordinario, una
directory, un link simbolico, una FIFO, un file di dispositivo, o una
-qualsiasi altra cosa che possa essere rappresentata dal VFS (sui tipi di
-``file'' possibili torneremo in seguito). A ciascuno di essi è associata pure
-una struttura che sta in memoria, e che oltre alle informazioni sullo
-specifico file contiene pure il riferimento alle funzioni (i \textsl{metodi})
-da usare per poterlo manipolare.
+qualsiasi altra cosa che possa essere rappresentata dal VFS (i tipi di
+``file'' riportati in \tabref{tab:file_file_types}). A ciascuno di essi è
+associata pure una struttura che sta in memoria, e che, oltre alle
+informazioni sullo specifico file, contiene anche il riferimento alle funzioni
+(i \textsl{metodi} del VFS) da usare per poterlo manipolare.
Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
-vengono usate per motivi di velocità, gli inode invece stanno su disco e
-vengono copiati in memoria quando serve, ed ogni cambiamento viene copiato
-all'indietro sul disco, gli inode che stanno in memoria sono inode del VFS ed
-è ad essi che puntano le singole \textit{dentry}.
+vengono usate per motivi di velocità, gli \textit{inode} invece stanno su
+disco e vengono copiati in memoria quando serve, ed ogni cambiamento viene
+copiato all'indietro sul disco, gli inode che stanno in memoria sono inode del
+VFS ed è ad essi che puntano le singole \textit{dentry}.
La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
strutture in memoria quando si effettua il montaggio lo specifico filesystem
su cui l'inode va a vivere.
-Una volta che il VFS ha a disposizione la dentry (ed il relativo inode)
-diventa possibile accedere alle varie operazioni sul file come la
-\func{open} per aprire il file o la \func{stat} per leggere i dati
+Una volta che il VFS ha a disposizione la \textit{dentry} (ed il relativo
+\textit{inode}) diventa possibile accedere alle varie operazioni sul file come
+la \func{open} per aprire il file o la \func{stat} per leggere i dati
dell'inode e passarli in user space.
L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
\label{tab:file_file_operations}
\end{table}
-In questo modo per ciascun file diventano utilizzabili una serie di operazioni
-(non è dette che tutte siano disponibili), che costituiscono l'interfaccia
-astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad
+In questo modo per ciascun file diventano possibili una serie di operazioni
+(non è detto che tutte siano disponibili), che costituiscono l'interfaccia
+astratta del VFS. Qualora se ne voglia eseguire una il kernel andrà ad
utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
-di file in questione.
+di file in questione.
-Così sarà possibile scrivere sulla porta seriale come su un file di dati
-normale; ovviamente certe operazioni (nel caso della seriale ad esempio la
-\code{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
-diversi filesystem (come quelli usati da Windows o MacOs) è immediato e
-(relativamente) trasparente per l'utente ed il programmatore.
+In questo modo è possibile scrivere allo stesso modo sulla porta seriale come
+su un file di dati normale; ovviamente certe operazioni (nel caso della
+seriale ad esempio la \code{seek}) non saranno disponibili, però con questo
+sistema l'utilizzo di diversi filesystem (come quelli usati da Windows o
+MacOs) è immediato e (relativamente) trasparente per l'utente ed il
+programmatore.
-\subsection{Il funzionamento di un filesystem unix}
+\subsection{Il funzionamento di un filesystem Unix}
\label{sec:file_filesystem}
-Come già accennato in \secref{sec:file_organization} Linux (ed ogni unix
-in generale) organizza i dati che tiene su disco attraverso l'uso di un
+Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema
+unix-like) organizza i dati che tiene su disco attraverso l'uso di un
filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
quella di poter supportare grazie al VFS una enorme quantità di filesystem
diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
-proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
-daremo una descrizione a grandi linee che si adatta alle caratteristiche
-comuni di un qualunque filesystem standard unix.
+proprie. Per questo per il momento non entreremo nei dettagli di un
+filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
+alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
-Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem; la strutturazione tipica
+Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
+partizione può contenere un filesystem. La strutturazione tipica
dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
-comune di tutti i filesystem unix, indipendentemente da come poi viene
+comune di tutti i filesystem per Unix, indipendentemente da come poi viene
strutturata nei dettagli questa informazione, prevedere una divisione fra la
lista degli inodes e lo spazio a disposizione per i dati e le directory.
\begin{figure}[htb]
\centering
- \includegraphics[width=9cm]{img/disk_struct}
+ \includegraphics[width=12cm]{img/disk_struct}
\caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
\label{fig:file_disk_filesys}
\end{figure}
\begin{figure}[htb]
\centering
- \includegraphics[width=11cm]{img/filesys_struct}
+ \includegraphics[width=12cm]{img/filesys_struct}
\caption{Strutturazione dei dati all'interno di un filesystem}
\label{fig:file_filesys_detail}
\end{figure}
-Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
-cui è bene porre attenzione in quanto sono fondamentali per capire il
-funzionamento delle funzioni che manipolano i file e le directory su cui
-torneremo in seguito; in particolare è opportuno ricordare sempre che:
+Da \curfig\ si evidenziano alcune delle caratteristiche di base di un
+filesystem, sulle quali è bene porre attenzione visto che sono fondamentali
+per capire il funzionamento delle funzioni che manipolano i file e le
+directory che tratteremo nel prossimo capitolo; in particolare è opportuno
+ricordare sempre che:
\begin{enumerate}
(traduzione approssimata dell'inglese \textit{directory entry}, che non
useremo anche per evitare confusione con le \textit{dentry} del kernel di
cui si parlava in \secref{sec:file_vfs}).
-
-\item Come mostrato in \curfig si possono avere più voci che puntano allo
+
+\item Come mostrato in \curfig\ si possono avere più voci che puntano allo
stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
solo quando questo contatore si annulla i dati del file vengono
file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
file, ma si limita a eliminare la relativa voce da una directory e
decrementare il numero di riferimenti nell'\textit{inode}.
-
+
\item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
nello stesso filesystem e non ci può essere una directory che contiene
riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
l'uso del comando \cmd{ln} (che crea una nuova voce per un file
esistente, con la funzione \func{link}) al filesystem corrente.
-
+
\item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
del file non deve essere spostato, viene semplicemente creata una nuova voce
per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
\end{enumerate}
-Infine è bene avere presente che essendo file pure loro, esiste un numero di
-riferimenti anche per le directory; per cui se ad esempio a partire dalla
-situazione mostrata in \curfig\ creiamo una nuova directory \file{img} nella
-directory \file{gapil}: avremo una situazione come quella in \nfig, dove per
-chiarezza abbiamo aggiunto dei numeri di inode.
+Infine è bene avere presente che, essendo file pure loro, esiste un numero di
+riferimenti anche per le directory; per cui se a partire dalla situazione
+mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
+\file{gapil}: avremo una situazione come quella in \nfig, dove per chiarezza
+abbiamo aggiunto dei numeri di inode.
\begin{figure}[htb]
\centering
- \includegraphics[width=11cm]{img/dir_links}
+ \includegraphics[width=12cm]{img/dir_links}
\caption{Organizzazione dei link per le directory}
\label{fig:file_dirs_link}
\end{figure}
Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
-caratteristiche di un filesystem standard unix, è in grado di gestire
-filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
-4~Tb.
+caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di
+file lunghi (256 caratteri, estendibili a 1012), una dimensione fino a 4~Tb.
-Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni
-che non sono presenti sugli altri filesystem unix, le cui principali sono le
+Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni che
+non sono presenti sugli altri filesystem Unix, le cui principali sono le
seguenti:
\begin{itemize}
\item i \textit{file attributes} consentono di modificare il comportamento del
log).
\end{itemize}
-La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD,
+La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD:
un filesystem è composto da un insieme di blocchi, la struttura generale è
quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
è divisa in gruppi di blocchi.
projects / gapil.git / commitdiff