X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=7601b73f57706a6a64eb3bc977245b2a41a0cafe;hp=24f331be5c9c42493f15c7a1a92f05ec612fcd3f;hb=6db03808a639644251507d0f90f953117f893866;hpb=470f15a82390d6120981e85202f45fc102f3e8a3 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