From: Simone Piccardi Date: Sun, 17 Feb 2002 23:14:45 +0000 (+0000) Subject: Correzioni varie parte terza X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=6db03808a639644251507d0f90f953117f893866 Correzioni varie parte terza --- diff --git a/filedir.tex b/filedir.tex index 24f331b..7601b73 100644 --- a/filedir.tex +++ b/filedir.tex @@ -4,11 +4,11 @@ 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. @@ -20,7 +20,7 @@ direttamente dall'architettura del sistema; in questa sezione esamineremo le 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. @@ -46,7 +46,8 @@ riferimento al suddetto inode. 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 @@ -90,9 +91,9 @@ meccanismo non 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 @@ -142,9 +143,10 @@ restrizioni 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 @@ -223,7 +225,7 @@ esiste, non deve essere una directory (altrimenti si ha l'errore \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 @@ -233,9 +235,9 @@ Se \var{oldpath} si riferisce a un link simbolico questo sar \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 @@ -246,7 +248,7 @@ eseguita. 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. @@ -256,16 +258,16 @@ 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 @@ -298,9 +300,8 @@ specificato. La funzione che permette di creare un nuovo link simbolico 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 @@ -362,12 +363,8 @@ la funzione \func{readlink}, il cui prototipo \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 @@ -382,7 +379,7 @@ stringa con un carattere nullo e la tronca alla dimensione specificata da \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} @@ -392,27 +389,28 @@ cosiddetti \textit{loop}. La situazione 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}%$ @@ -424,8 +422,8 @@ quanto aprendo in scrittura \file{temporaneo} verr $ 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} @@ -460,7 +458,7 @@ accedere ai tipi usati da queste funzioni si deve includere il file \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 @@ -512,7 +510,7 @@ Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in 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 è: @@ -542,9 +540,9 @@ di queste funzioni 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 @@ -560,7 +558,7 @@ usando questa funzione; ma in Linux\footnote{la funzione non 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. @@ -576,7 +574,7 @@ Per creare una fifo (un file speciale, su cui torneremo in dettaglio in \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 @@ -671,8 +669,8 @@ pathname ricavato risalendo all'indietro l'albero della directory, si 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}. @@ -711,7 +709,7 @@ specificata da \param{fd}. \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 @@ -750,12 +748,12 @@ esplicitamente, il suo prototipo \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 @@ -788,8 +786,8 @@ POSIX definisce la funzione \func{tempfile}, il cui prototipo 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 è @@ -817,9 +815,9 @@ funzione non si pu 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. @@ -838,9 +836,9 @@ prototipo 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 @@ -913,12 +911,15 @@ queste funzioni sono i seguenti: \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 @@ -956,15 +957,16 @@ del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in \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 @@ -987,10 +989,17 @@ riportato in \ntab. \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 @@ -1033,11 +1042,9 @@ per questo sempre in \file{sys/stat.h} sono definiti i flag riportati in \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} @@ -1045,12 +1052,12 @@ in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e 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 @@ -1060,12 +1067,12 @@ dimensione inferiore sarebbe inefficiente. 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 @@ -1079,7 +1086,8 @@ presenti al di l 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 @@ -1130,7 +1138,7 @@ riportato un esempio delle funzioni che effettuano cambiamenti su di essi. \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}, @@ -1187,18 +1195,20 @@ quest'ultimo. \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 @@ -1229,9 +1239,9 @@ quest'ultimo. \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} @@ -1253,7 +1263,7 @@ quest'ultimo. \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. @@ -1316,50 +1326,50 @@ le funzioni usate per gestirne i vari aspetti. \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 diff --git a/fileintro.tex b/fileintro.tex index 010add3..40d8e25 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -176,7 +176,8 @@ Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di 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. @@ -296,23 +297,23 @@ POSIX.1 dei sistemi Unix, ed 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 @@ -322,13 +323,14 @@ maniera un po' pi % \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 @@ -361,17 +363,17 @@ In questo modo quando viene effettuata la richiesta di montare un nuovo disco (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 @@ -386,28 +388,28 @@ file gi \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 è @@ -421,9 +423,9 @@ della directory che contiene il file; questo viene installato nelle relative 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 @@ -464,44 +466,45 @@ operazioni previste dal kernel \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} @@ -514,15 +517,16 @@ esemplificare la situazione con uno schema come quello esposto in \nfig. \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} @@ -535,8 +539,8 @@ torneremo in seguito; in particolare (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 @@ -544,13 +548,13 @@ torneremo in seguito; in particolare 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à @@ -559,15 +563,15 @@ torneremo in seguito; in particolare \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} @@ -586,12 +590,11 @@ adesso sar 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 @@ -620,7 +623,7 @@ seguenti: 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.