From caf486b327fb878e112c24b48d701a3b1d079e62 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Thu, 28 Aug 2008 18:06:59 +0000 Subject: [PATCH] Serie di precisazione relative alla gestione degli hardlink su symbolic link (ispirata da articolo di LWN), e corretta anche la tabella sul comportamento delle funzioni che operano sui link simbolici (per lchown che riportata un valore sbagliato e per link stessa). Corretta e ampliata la descrizione di mknod. Indicizzazione e italicizzazione di inode. --- filedir.tex | 378 ++++++++++++++++++++++++++++---------------------- fileintro.tex | 23 ++- 2 files changed, 224 insertions(+), 177 deletions(-) diff --git a/filedir.tex b/filedir.tex index 0785192..d4a7015 100644 --- a/filedir.tex +++ b/filedir.tex @@ -26,17 +26,15 @@ dei file \section{La gestione di file e directory} \label{sec:file_dir} -Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like la -gestione dei file ha delle caratteristiche specifiche che derivano -direttamente dall'architettura del sistema. - -In questa sezione esamineremo le funzioni usate per la manipolazione di file e -directory, per la creazione di link simbolici e diretti, per la gestione e la -lettura delle directory. +Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like +la gestione dei file ha delle caratteristiche specifiche che derivano +direttamente dall'architettura del sistema. In questa sezione esamineremo le +funzioni usate per la manipolazione di file e directory, per la creazione di +link simbolici e diretti, per la gestione e la lettura delle directory. In particolare ci soffermeremo sulle conseguenze che derivano dall'architettura dei filesystem illustrata nel capitolo precedente per quanto -riguarda il comportamento delle varie funzioni. +riguarda il comportamento e gli effetti delle varie funzioni. \subsection{Le funzioni \func{link} e \func{unlink}} @@ -54,24 +52,25 @@ sez.~\ref{sec:file_arch_func}) ci sono due metodi sostanzialmente diversi per fare questa operazione. Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un -file su disco avviene passando attraverso il suo \index{inode} inode, che è la -struttura usata dal kernel che lo identifica univocamente all'interno di un -singolo filesystem. Il nome del file che si trova nella voce di una directory -è solo un'etichetta, mantenuta all'interno della directory, che viene -associata ad un puntatore che fa riferimento al suddetto inode. +file su disco avviene passando attraverso il suo \itindex{inode} +\textit{inode}, che è la struttura usata dal kernel che lo identifica +univocamente all'interno di un singolo filesystem. Il nome del file che si +trova nella voce di una directory è solo un'etichetta, mantenuta all'interno +della directory, che viene associata ad un puntatore che fa riferimento al +suddetto \textit{inode}. Questo significa che, fintanto che si resta sullo stesso filesystem, la realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi -diversi, dati da altrettante diverse associazioni allo stesso \index{inode} -inode di etichette diverse in directory diverse. Si noti anche che nessuno di -questi nomi viene ad assumere una particolare preferenza o originalità -rispetto agli altri, in quanto tutti fanno comunque riferimento allo stesso -\index{inode} inode. +diversi, dati da altrettante associazioni diverse allo stesso \itindex{inode} +\textit{inode} effettuate tramite ``etichette'' diverse in directory +diverse. Si noti anche che nessuno di questi nomi viene ad assumere una +particolare preferenza o originalità rispetto agli altri, in quanto tutti +fanno comunque riferimento allo stesso \itindex{inode} \textit{inode}. Per aggiungere ad una directory una voce che faccia riferimento ad un -\index{inode} inode già esistente si utilizza la funzione \func{link}; si -suole chiamare questo tipo di associazione un collegamento diretto (o -\textit{hard link}). Il prototipo della funzione è: +\itindex{inode} \textit{inode} già esistente si utilizza la funzione +\func{link}; si suole chiamare questo tipo di associazione un collegamento +diretto, o \textit{hard link}. Il prototipo della funzione è il seguente: \begin{prototype}{unistd.h} {int link(const char *oldpath, const char *newpath)} Crea un nuovo collegamento diretto. @@ -79,12 +78,12 @@ suole chiamare questo tipo di associazione un collegamento diretto (o \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di errore nel qual caso \var{errno} viene impostata ai valori: \begin{errlist} - \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non sono - sullo stesso filesystem. + \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno + riferimento ad un filesystem montato sullo stesso \textit{mount point}. \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e \param{newpath} non supporta i link diretti o è una directory. - \item[\errcode{EEXIST}] un file (o una directory) con quel nome esiste di - già. + \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath} + esiste già. \item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi sez.~\ref{sec:sys_limits}). @@ -102,12 +101,17 @@ ad aumentare di uno il numero di riferimenti al file (riportato nel campo \var{st\_nlink} della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat}) aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può essere così chiamato con vari nomi in diverse directory. - + Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un collegamento diretto è possibile solo se entrambi i \itindex{pathname} \textit{pathname} sono nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti diretti (il meccanismo non è disponibile ad esempio -con il filesystem \acr{vfat} di Windows). +con il filesystem \acr{vfat} di Windows). In realtà la funzione ha un +ulteriore requisito, e cioè che non solo che i due file siano sullo stesso +filesystem, ma anche che si faccia riferimento ad essi sullo stesso +\textit{mount point}.\footnote{si tenga presente infatti (vedi + sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno stesso + filesystem può essere montato più volte su directory diverse.} La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo @@ -121,9 +125,41 @@ programma \cmd{fsck} per riparare il filesystem). Data la pericolosità di questa operazione e la disponibilità dei link simbolici che possono fornire la stessa funzionalità senza questi problemi, -nei filesystem usati in Linux questa caratteristica è stata completamente -disabilitata, e al tentativo di creare un link diretto ad una directory la -funzione restituisce l'errore \errcode{EPERM}. +nel caso di Linux questa capacità è stata completamente disabilitata, e al +tentativo di creare un link diretto ad una directory la funzione \func{link} +restituisce l'errore \errcode{EPERM}. + +Un ulteriore comportamento peculiare di Linux è quello in cui si crea un +\textit{hard link} ad un link simbolico. In questo caso lo standard POSIX +prevederebbe che quest'ultimo venga risolto e che il collegamento sia +effettuato rispetto al file cui esso punta, e che venga riportato un errore +qualora questo non esista o non sia un file. Questo era anche il comportamento +iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la + precisione il comportamento era quello previsto dallo standard POSIX fino al + kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche + durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento + attuale fino ad oggi (per riferimento si veda + \href{http://lwn.net/Articles/293902} + {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un +comportamento che non segue più lo standard per cui l'\textit{hard link} viene +creato rispetto al link simbolico, e non al file cui questo punta. + +La ragione di questa differenza rispetto allo standard, presente anche in +altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare +riferimento anche ad un file non esistente o a una directory, per i quali +l'\textit{hard link} non può essere creato, per cui la scelta di seguire il +link simbolico è stata ritenuta una scelta scorretta nella progettazione +dell'interfaccia. Infatti se non ci fosse il comportamento adottato da Linux +sarebbe impossibile creare un \textit{hard link} ad un link simbolico, perché +la funzione lo risolverebbe e l'\textit{hard link} verrebbe creato verso la +destinazione. Invece evitando di seguire lo standard l'operazione diventa +possibile, ed anche il comportamento della funzione risulta molto più +comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard + link} rispetto alla destinazione di un link simbolico è sempre possibile +farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori + standard possa causare problemi, come nell'esempio descritto nell'articolo + citato nella nota precedente, a programmi che non si aspettano questa + differenza rispetto allo standard POSIX.} La rimozione di un file (o più precisamente della voce che lo referenzia all'interno di una directory) si effettua con la funzione \funcd{unlink}; il @@ -154,10 +190,10 @@ suo prototipo abbia privilegi sufficienti.} La funzione cancella il nome specificato da \param{pathname} nella relativa -directory e decrementa il numero di riferimenti nel relativo \index{inode} -inode. Nel caso di link simbolico cancella il link simbolico; nel caso di -socket, fifo o file di dispositivo \index{file!di~dispositivo} rimuove il -nome, ma come per i file i processi che hanno aperto uno di questi oggetti +directory e decrementa il numero di riferimenti nel relativo \itindex{inode} +\textit{inode}. Nel caso di link simbolico cancella il link simbolico; nel +caso di socket, fifo o file di dispositivo \index{file!di~dispositivo} rimuove +il nome, ma come per i file i processi che hanno aperto uno di questi oggetti possono continuare ad utilizzarlo. Per cancellare una voce in una directory è necessario avere il permesso di @@ -171,23 +207,23 @@ root, per cui nessuna delle restrizioni Una delle caratteristiche di queste funzioni è che la creazione/rimozione del nome dalla directory e l'incremento/decremento del numero di riferimenti -\index{inode} nell'inode devono essere effettuati in maniera atomica (si veda -sez.~\ref{sec:proc_atom_oper}) senza possibili interruzioni fra le due -operazioni. Per questo entrambe queste funzioni sono realizzate tramite una -singola system call. +\itindex{inode} nell'\textit{inode} devono essere effettuati in maniera +atomica (si veda sez.~\ref{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 un file non viene eliminato dal disco fintanto che tutti i riferimenti ad esso sono stati cancellati: solo quando il \textit{link - count} mantenuto \index{inode} nell'inode diventa zero lo spazio occupato su -disco viene rimosso (si ricordi comunque che a questo si aggiunge sempre -un'ulteriore condizione,\footnote{come vedremo in + count} mantenuto \itindex{inode} nell'\textit{inode} diventa zero lo spazio +occupato su disco viene rimosso (si ricordi comunque che a questo si aggiunge +sempre un'ulteriore condizione,\footnote{come vedremo in cap.~\ref{cha:file_unix_interface} il kernel mantiene anche una tabella dei file aperti nei vari processi, che a sua volta contiene i riferimenti agli - \index{inode} inode ad essi relativi. Prima di procedere alla cancellazione - dello spazio occupato su disco dal contenuto di un file il kernel controlla - anche questa tabella, per verificare che anche in essa non ci sia più nessun - riferimento all'inode in questione.} e cioè che non ci siano processi che -abbiano il suddetto file aperto). + \itindex{inode} \textit{inode} ad essi relativi. Prima di procedere alla + cancellazione dello spazio occupato su disco dal contenuto di un file il + kernel controlla anche questa tabella, per verificare che anche in essa non + ci sia più nessun riferimento all'\textit{inode} in questione.} e cioè che +non ci siano processi che abbiano il suddetto file aperto). Questa proprietà viene spesso usata per essere sicuri di non lasciare file temporanei su disco in caso di crash dei programmi; la tecnica è quella di @@ -307,10 +343,10 @@ riferimento allo stesso file. \label{sec:file_symlink} Come abbiamo visto in sez.~\ref{sec:file_link} la funzione \func{link} crea -riferimenti agli \index{inode} inode, pertanto può funzionare soltanto per file -che 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. +riferimenti agli \itindex{inode} \textit{inode}, pertanto può funzionare +soltanto per file che 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 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono, @@ -322,13 +358,13 @@ file che non esistono ancora. Il sistema funziona in quanto i link simbolici sono riconosciuti come tali dal kernel\footnote{è uno dei diversi tipi di file visti in - tab.~\ref{tab:file_file_types}, contrassegnato come tale nell'inode, e - riconoscibile dal valore del campo \var{st\_mode} della struttura - \struct{stat} (vedi sez.~\ref{sec:file_stat}).} per cui alcune funzioni di -libreria (come \func{open} o \func{stat}) quando ricevono come argomento un -link simbolico vengono automaticamente applicate al file da esso specificato. -La funzione che permette di creare un nuovo link simbolico è \funcd{symlink}, -ed il suo prototipo è: + tab.~\ref{tab:file_file_types}, contrassegnato come tale + nell'\textit{inode}, e riconoscibile dal valore del campo \var{st\_mode} + della struttura \struct{stat} (vedi sez.~\ref{sec:file_stat}).} per cui +alcune funzioni di libreria (come \func{open} o \func{stat}) quando ricevono +come argomento un link simbolico vengono automaticamente applicate al file da +esso specificato. La funzione che permette di creare un nuovo link simbolico +è \funcd{symlink}, ed il suo prototipo è: \begin{prototype}{unistd.h} {int symlink(const char *oldpath, const char *newpath)} Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è @@ -376,8 +412,8 @@ direttamente sul suo contenuto. \func{chown} & -- & $\bullet$ \\ \func{creat} & $\bullet$ & -- \\ \func{exec} & $\bullet$ & -- \\ - \func{lchown} & $\bullet$ & $\bullet$ \\ - \func{link} & -- & -- \\ + \func{lchown} & $\bullet$ & -- \\ + \func{link}\footnotemark & -- & $\bullet$ \\ \func{lstat} & -- & $\bullet$ \\ \func{mkdir} & $\bullet$ & -- \\ \func{mkfifo} & $\bullet$ & -- \\ @@ -397,6 +433,9 @@ direttamente sul suo contenuto. \label{tab:file_symb_effect} \end{table} +\footnotetext{a partire dalla serie 2.0, e contrariamente a quanto indicato + dallo standard POSIX, si veda quanto detto in sez.~\ref{sec:file_link}.} + Si noti che non si è specificato il comportamento delle funzioni che operano con i file descriptor, in quanto la risoluzione del link simbolico viene in genere effettuata dalla funzione che restituisce il file descriptor @@ -484,12 +523,12 @@ ci mostrerebbe invece l'esistenza di \file{temporaneo}. \label{sec:file_dir_creat_rem} Benché in sostanza le directory non siano altro che dei file contenenti -elenchi di nomi ed \index{inode} inode, non è possibile trattarle come file -ordinari e devono essere create direttamente dal kernel attraverso una -opportuna system call.\footnote{questo è quello che permette anche, attraverso - l'uso del VFS, l'utilizzo di diversi formati per la gestione dei suddetti - elenchi.} La funzione usata per creare una directory è \funcd{mkdir}, ed il -suo prototipo è: +elenchi di nomi ed \itindex{inode} \textit{inode}, non è possibile trattarle +come file ordinari e devono essere create direttamente dal kernel attraverso +una opportuna system call.\footnote{questo è quello che permette anche, + attraverso l'uso del VFS, l'utilizzo di diversi formati per la gestione dei + suddetti elenchi.} La funzione usata per creare una directory è +\funcd{mkdir}, ed il suo prototipo è: \begin{functions} \headdecl{sys/stat.h} \headdecl{sys/types.h} @@ -562,12 +601,13 @@ directory deve cio \textit{pathname} assoluto o relativo. La modalità con cui avviene la cancellazione è analoga a quella di -\func{unlink}: fintanto che il numero di link \index{inode} all'inode della -directory non diventa nullo e nessun processo ha la directory aperta lo spazio -occupato su disco non viene rilasciato. Se un processo ha la directory aperta -la funzione rimuove il link \index{inode} all'inode e nel caso sia l'ultimo, -pure le voci standard ``\file{.}'' e ``\file{..}'', a questo punto il kernel -non consentirà di creare più nuovi file nella directory. +\func{unlink}: fintanto che il numero di link \itindex{inode} +all'\textit{inode} della directory non diventa nullo e nessun processo ha la +directory aperta lo spazio occupato su disco non viene rilasciato. Se un +processo ha la directory aperta la funzione rimuove il link \itindex{inode} +all'\textit{inode} e nel caso sia l'ultimo, pure le voci standard ``\file{.}'' +e ``\file{..}'', a questo punto il kernel non consentirà di creare più nuovi +file nella directory. \subsection{La creazione di file speciali} @@ -590,16 +630,16 @@ di queste funzioni \headdecl{unistd.h} \funcdecl{int mknod(const char *pathname, mode\_t mode, dev\_t dev)} - Crea un inode, si usa per creare i file speciali. + Crea un \textit{inode} del tipo specificato sul filesystem. \bodydesc{La funzione restituisce zero in caso di successo e -1 per un errore, nel qual caso \var{errno} assumerà i valori: \begin{errlist} - \item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare l'inode, o - il filesystem su cui si è cercato di creare \param{pathname} non supporta - l'operazione. + \item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare + l'\texttt{inode}, o il filesystem su cui si è cercato di + creare \param{pathname} non supporta l'operazione. \item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una - fifo o un dispositivo. + fifo, un socket o un dispositivo. \item[\errcode{EEXIST}] \param{pathname} esiste già o è un link simbolico. \end{errlist} ed inoltre anche \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG}, @@ -616,22 +656,26 @@ permessi sono comunque modificati nella maniera usuale dal valore di Per il tipo di file può essere specificato solo uno fra: \const{S\_IFREG} per un file regolare (che sarà creato vuoto), \const{S\_IFBLK} per un dispositivo -a blocchi, \const{S\_IFCHR} per un dispositivo a caratteri e \const{S\_IFIFO} -per una fifo. Un valore diverso comporterà l'errore \errcode{EINVAL}. Qualora -si sia specificato in \param{mode} un file di dispositivo, il valore di -\param{dev} viene usato per indicare a quale dispositivo si fa riferimento. - -Solo l'amministratore può creare un file di dispositivo o un file regolare -usando questa funzione; ma in Linux\footnote{la funzione non è prevista dallo - standard POSIX, e deriva da SVr4, con appunto questa differenza e diversi - codici di errore.} l'uso per la creazione di una fifo è consentito anche -agli utenti normali. - -I nuovi \index{inode} inode creati con \func{mknod} apparterranno al -proprietario e al 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 sez.~\ref{sec:file_ownership_management}) in -cui si va a creare \index{inode} l'inode. +a blocchi, \const{S\_IFCHR} per un dispositivo a caratteri, \const{S\_IFSOCK} +e \const{S\_IFIFO} per una fifo. Un valore diverso comporterà l'errore +\errcode{EINVAL}. Qualora si sia specificato in \param{mode} un file di +dispositivo (\const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} +dovrà essere usato per indicare a quale dispositivo si fa riferimento con il +relativo numero. + +Solo l'amministratore può creare un file di dispositivo usando questa funzione +(il processo deve avere la \textit{capability} \const{CAP\_MKNOD}); ma in +Linux\footnote{la funzione non è prevista dallo standard POSIX, e deriva da + SVr4, con appunto questa differenza e diversi codici di errore.} l'uso per +la creazione di un file ordinario, di una fifo o di un socket è consentito +anche agli utenti normali. + +I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno +al proprietario e al 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 +sez.~\ref{sec:file_ownership_management}) in cui si va a creare +\itindex{inode} l'\textit{inode}. Per creare una fifo (un file speciale, su cui torneremo in dettaglio in sez.~\ref{sec:ipc_named_pipe}) lo standard POSIX specifica l'uso della funzione @@ -660,12 +704,12 @@ modificati dal valore di \itindex{umask} \textit{umask}. \label{sec:file_dir_read} Benché le directory alla fine non siano altro che dei file che contengono -delle liste di nomi ed \index{inode} inode, per il ruolo che rivestono nella -struttura del sistema, non possono essere trattate come dei normali file di -dati. Ad esempio, onde evitare inconsistenze all'interno del filesystem, solo -il kernel può scrivere il contenuto di una directory, e non può essere un -processo a inserirvi direttamente delle voci con le usuali funzioni di -scrittura. +delle liste di nomi ed \itindex{inode} \textit{inode}, per il ruolo che +rivestono nella struttura del sistema, non possono essere trattate come dei +normali file di dati. Ad esempio, onde evitare inconsistenze all'interno del +filesystem, solo il kernel può scrivere il contenuto di una directory, e non +può essere un processo a inserirvi direttamente delle voci con le usuali +funzioni di scrittura. Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del kernel, sono molte le situazioni in cui i processi necessitano di poterne @@ -784,8 +828,8 @@ una stringa terminata da uno zero,\footnote{lo standard POSIX non specifica una lunghezza, ma solo un limite \const{NAME\_MAX}; in SVr4 la lunghezza del campo è definita come \code{NAME\_MAX+1} che di norma porta al valore di 256 byte usato anche in Linux.} ed il campo \var{d\_ino}, che contiene il numero -di \index{inode} inode cui il file è associato (di solito corrisponde al campo -\var{st\_ino} di \struct{stat}). +di \itindex{inode} \textit{inode} cui il file è associato (di solito +corrisponde al campo \var{st\_ino} di \struct{stat}). \begin{figure}[!htb] \footnotesize \centering @@ -1072,10 +1116,10 @@ resta la stessa quando viene creato un processo figlio (vedi sez.~\ref{sec:proc_fork}), la directory corrente della shell diventa anche la directory corrente di qualunque comando da essa lanciato. -In genere il kernel tiene traccia per ciascun processo \index{inode} -dell'inode della directory di lavoro, per ottenere il \textit{pathname} -occorre usare una apposita funzione di libreria, \funcd{getcwd}, il cui -prototipo è: +In genere il kernel tiene traccia per ciascun processo \itindex{inode} +dell'\textit{inode} della directory di lavoro, per ottenere il +\textit{pathname} occorre usare una apposita funzione di libreria, +\funcd{getcwd}, il cui prototipo è: \begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)} Legge il \textit{pathname} della directory di lavoro corrente. @@ -1333,13 +1377,14 @@ della directory Come spiegato in sez.~\ref{sec:file_filesystem} tutte le informazioni generali relative alle caratteristiche di ciascun file, a partire dalle informazioni -relative al controllo di accesso, sono mantenute \index{inode} nell'inode. +relative al controllo di accesso, sono mantenute \itindex{inode} +nell'\textit{inode}. Vedremo in questa sezione come sia possibile leggere tutte queste informazioni usando la funzione \func{stat}, che permette l'accesso a tutti i dati -memorizzati \index{inode} nell'inode; esamineremo poi le varie funzioni usate -per manipolare tutte queste informazioni (eccetto quelle che riguardano la -gestione del controllo di accesso, trattate in in +memorizzati \itindex{inode} nell'\textit{inode}; esamineremo poi le varie +funzioni usate per manipolare tutte queste informazioni (eccetto quelle che +riguardano la gestione del controllo di accesso, trattate in in sez.~\ref{sec:file_access_control}). @@ -1575,12 +1620,12 @@ zeri (e in genere si ha la creazione di un \textit{hole} nel file). \label{sec:file_file_times} Il sistema mantiene per ciascun file tre tempi. Questi sono registrati -\index{inode} nell'inode insieme agli altri attributi del file e possono -essere letti tramite la funzione \func{stat}, che li restituisce attraverso -tre campi della struttura \struct{stat} di fig.~\ref{fig:file_stat_struct}. Il -significato di detti tempi e dei relativi campi è riportato nello schema in -tab.~\ref{tab:file_file_times}, dove è anche riportato un esempio delle -funzioni che effettuano cambiamenti su di essi. +\itindex{inode} nell'\textit{inode} insieme agli altri attributi del file e +possono essere letti tramite la funzione \func{stat}, che li restituisce +attraverso tre campi della struttura \struct{stat} di +fig.~\ref{fig:file_stat_struct}. Il significato di detti tempi e dei relativi +campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche +riportato un esempio delle funzioni che effettuano cambiamenti su di essi. \begin{table}[htb] \centering @@ -1595,7 +1640,7 @@ funzioni che effettuano cambiamenti su di essi. \func{read}, \func{utime} & \cmd{-u}\\ \var{st\_mtime}& ultima modifica ai dati del file & \func{write}, \func{utime} & default\\ - \var{st\_ctime}& ultima modifica ai dati dell'inode & + \var{st\_ctime}& ultima modifica ai dati dell'\textit{inode} & \func{chmod}, \func{utime} & \cmd{-c}\\ \hline \end{tabular} @@ -1607,18 +1652,18 @@ Il primo punto da tenere presente modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di cambiamento di stato (il \textit{change time} \var{st\_ctime}). Il primo infatti fa riferimento ad una modifica del contenuto di un file, mentre il -secondo ad una modifica \index{inode} dell'inode; siccome esistono molte -operazioni (come la funzione \func{link} e molte altre che vedremo in seguito) -che modificano solo le informazioni contenute \index{inode} nell'inode senza -toccare il contenuto del file, diventa necessario l'utilizzo di un altro -tempo. - -Il sistema non tiene conto dell'ultimo accesso \index{inode} all'inode, -pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza -sui tre tempi. Il tempo di ultimo accesso (ai dati) viene di solito usato per -cancellare i file che non servono più dopo un certo lasso di tempo (ad esempio -il programma \cmd{leafnode} cancella i vecchi articoli sulla base di questo -tempo). +secondo ad una modifica \itindex{inode} dell'\textit{inode}; siccome esistono +molte operazioni (come la funzione \func{link} e molte altre che vedremo in +seguito) che modificano solo le informazioni contenute \itindex{inode} +nell'\textit{inode} senza toccare il contenuto del file, diventa necessario +l'utilizzo di un altro tempo. + +Il sistema non tiene conto dell'ultimo accesso \itindex{inode} +all'\textit{inode}, pertanto funzioni come \func{access} o \func{stat} non +hanno alcuna influenza sui tre tempi. Il tempo di ultimo accesso (ai dati) +viene di solito usato per cancellare i file che non servono più dopo un certo +lasso di tempo (ad esempio il programma \cmd{leafnode} cancella i vecchi +articoli sulla base di questo tempo). \begin{table}[htb] \centering @@ -1733,9 +1778,10 @@ funzione \funcd{utime}, il cui prototipo \begin{prototype}{utime.h} {int utime(const char *filename, struct utimbuf *times)} -Cambia i tempi di ultimo accesso e modifica \index{inode} dell'inode -specificato da \param{filename} secondo i campi \var{actime} e \var{modtime} -di \param{times}. Se questa è \val{NULL} allora viene usato il tempo corrente. +Cambia i tempi di ultimo accesso e modifica \itindex{inode} +dell'\textit{inode} specificato da \param{filename} secondo i campi +\var{actime} e \var{modtime} di \param{times}. Se questa è \val{NULL} allora +viene usato il tempo corrente. \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: @@ -1769,12 +1815,12 @@ del file (o si hanno i privilegi di amministratore). Si tenga presente che non è comunque possibile specificare il tempo di cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le -volte che si modifica \index{inode} l'inode (quindi anche alla chiamata di -\func{utime}). Questo serve anche come misura di sicurezza per evitare che si -possa modificare un file nascondendo completamente le proprie tracce. In -realtà la cosa resta possibile, se si è in grado di accedere al file di -dispositivo, scrivendo direttamente sul disco senza passare attraverso il -filesystem, ma ovviamente in questo modo la cosa è molto più complicata da +volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche alla +chiamata di \func{utime}). Questo serve anche come misura di sicurezza per +evitare che si possa modificare un file nascondendo completamente le proprie +tracce. In realtà la cosa resta possibile, se si è in grado di accedere al +file di dispositivo, scrivendo direttamente sul disco senza passare attraverso +il filesystem, ma ovviamente in questo modo la cosa è molto più complicata da realizzare. @@ -1851,9 +1897,9 @@ sez.~\ref{sec:file_special_perm}); lo schema di allocazione dei bit riportato in fig.~\ref{fig:file_perm_bit}. Anche i permessi, come tutte le altre informazioni pertinenti al file, sono -memorizzati \index{inode} nell'inode; in particolare essi sono contenuti in -alcuni bit del campo \var{st\_mode} della struttura \struct{stat} (si veda di -nuovo fig.~\ref{fig:file_stat_struct}). +memorizzati \itindex{inode} nell'\textit{inode}; in particolare essi sono +contenuti in alcuni bit del campo \var{st\_mode} della struttura \struct{stat} +(si veda di nuovo fig.~\ref{fig:file_stat_struct}). In genere ci si riferisce ai tre livelli dei privilegi usando le lettere \cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o} (per @@ -2555,14 +2601,15 @@ Linux. \itindbeg{Extended~Attributes} Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni -che il sistema mantiene negli inode, e le varie funzioni che permettono di -modificarle. Si sarà notato come in realtà queste informazioni siano -estremamente ridotte. Questo è dovuto al fatto che Unix origina negli anni -'70, quando le risorse di calcolo e di spazio disco erano minime. Con il venir -meno di queste restrizioni è incominciata ad emergere l'esigenza di poter -associare ai file delle ulteriori informazioni astratte (quelli che vengono -chiamati i \textsl{meta-dati}) che però non potevano trovare spazio nei dati -classici mantenuti negli inode. +che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie +funzioni che permettono di modificarle. Si sarà notato come in realtà queste +informazioni siano estremamente ridotte. Questo è dovuto al fatto che Unix +origina negli anni '70, quando le risorse di calcolo e di spazio disco erano +minime. Con il venir meno di queste restrizioni è incominciata ad emergere +l'esigenza di poter associare ai file delle ulteriori informazioni astratte +(quelli che vengono chiamati i \textsl{meta-dati}) che però non potevano +trovare spazio nei dati classici mantenuti negli \itindex{inode} +\textit{inode}. Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche Linux) hanno introdotto un meccanismo generico che consenta di associare delle @@ -2585,10 +2632,10 @@ efficienti,\footnote{cosa molto importante, specie per le applicazioni che richiedono una gran numero di accessi, come le ACL.} e di garantire l'atomicità di tutte le operazioni. -In Linux gli attributi estesi sono sempre associati al singolo inode e -l'accesso viene sempre eseguito in forma atomica, in lettura il valore -corrente viene scritto su un buffer in memoria, mentre la scrittura prevede -che ogni valore precedente sia sovrascritto. +In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode} +\textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura +il valore corrente viene scritto su un buffer in memoria, mentre la scrittura +prevede che ogni valore precedente sia sovrascritto. Si tenga presente che non tutti i filesystem supportano gli \textit{Extended Attributes}, in particolare al momento della scrittura di queste dispense @@ -2599,11 +2646,11 @@ quantit all'interno di un singolo blocco (pertanto con dimensioni massime pari a 1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono - limiti ed i dati vengono memorizzati in maniera diversa (nell'inode stesso, - in un blocco a parte, o in una struttura ad albero dedicata) per mantenerne - la scalabilità.} Infine lo spazio utilizzato per mantenere gli attributi -estesi viene tenuto in conto per il calcolo delle quote di utente e gruppo -proprietari del file. + limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode} + stesso, in un blocco a parte, o in una struttura ad albero dedicata) per + mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli +attributi estesi viene tenuto in conto per il calcolo delle quote di utente e +gruppo proprietari del file. Come meccanismo per mantenere informazioni aggiuntive associate al singolo file, gli \textit{Extended Attributes} possono avere usi anche molto diversi @@ -3111,7 +3158,7 @@ valore per i permessi ordinari;\footnote{tutte le funzioni citate in permessi iniziale.} in tal caso saranno eliminati dalle voci corrispondenti nella ACL tutti quelli non presenti in tale indicazione. -Dato che questa è la ragione che ha portato alla loro creazione, la pricipale +Dato che questa è la ragione che ha portato alla loro creazione, la principale modifica introdotta con la presenza della ACL è quella alle regole del controllo di accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}. Come nel caso ordinario per il controllo vengono sempre utilizzati gli @@ -3203,7 +3250,7 @@ confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''. Una volta che si siano completate le operazioni sui dati di una ACL la memoria allocata dovrà essere liberata esplicitamente attraverso una chiamata alla -funzione \funcd{acl\_free}, il cui protipo è: +funzione \funcd{acl\_free}, il cui prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{sys/acl.h} @@ -3341,7 +3388,7 @@ assumere solo i due valori riportati in tab.~\ref{tab:acl_type}. \end{table} Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il -processo chiamante abbia privilegi di accesso sufficenti a poter leggere gli +processo chiamante abbia privilegi di accesso sufficienti a poter leggere gli attributi estesi dei file (come illustrati in sez.~\ref{sec:file_xattr}); inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta soltanto per una directory, e verrà restituita solo se presente, altrimenti @@ -3437,7 +3484,7 @@ La funzione restituisce il puntatore ad una stringa terminata da NUL contenente la rappresentazione in forma estesa della ACL passata come argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi essere liberata, quando non più necessaria, con \func{acl\_free}. Se -nell'argomento \param{len\_p} si passa un valore puntatote ad una variabile +nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile intera in questa verrà restituita la dimensione della stringa con la rappresentazione testuale (non comprendente il carattere nullo finale). @@ -3623,20 +3670,20 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: un'etichetta int const char oldpath newpath errno EXDEV EPERM st % LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls % LocalWords: ELOOP ENOSPC EIO pathname nlink stat vfat fsck EISDIR ENOENT cap -% LocalWords: POSIX socket fifo sticky root nell'inode system call count crash -% LocalWords: all'inode descriptor remove rename rmdir stdio glibc libc NFS DT +% LocalWords: POSIX socket fifo sticky root system call count crash nell' init +% LocalWords: descriptor remove rename rmdir stdio glibc libc NFS DT obj dup % LocalWords: ENOTEMPTY EBUSY mount point EINVAL soft symbolic tab symlink fig % LocalWords: dangling access chdir chmod chown creat exec lchown lstat mkdir % LocalWords: mkfifo mknod opendir pathconf readlink truncate path buff size % LocalWords: grub bootloader grep linux MAXSYMLINKS cat VFS sys dirname fcntl -% LocalWords: dev l'inode umask IFREG IFBLK IFCHR IFIFO SVr sgid BSD SVID NULL +% LocalWords: dev umask IFREG IFBLK IFCHR IFIFO SVr sgid BSD SVID NULL from to % LocalWords: stream dirent EMFILE ENFILE dirfd SOURCE fchdir readdir struct % LocalWords: EBADF namlen HAVE thread entry result value argument fileno ino % LocalWords: name TYPE OFF RECLEN UNKNOWN REG SOCK CHR BLK type IFTODT DTTOIF % LocalWords: DTYPE off reclen seekdir telldir void rewinddir closedir select % LocalWords: namelist compar malloc qsort alphasort versionsort strcoll myls % LocalWords: strcmp DirScan direntry while current working home shell pwd get -% LocalWords: dell'inode getcwd ERANGE getwd change fd race condition tmpnam +% LocalWords: getcwd ERANGE getwd change fd race condition tmpnam getfacl mark % LocalWords: string tmpdir TMP tempnam pfx TMPNAME suid tmp EXCL tmpfile pid % LocalWords: EINTR mktemp mkstemp stlib template filename XXXXXX OpenBSD buf % LocalWords: mkdtemp fstat filedes nell'header padding ISREG ISDIR ISCHR IFMT @@ -3654,9 +3701,10 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: fgetxattr attr ssize ENOATTR ENOTSUP NUL setxattr lsetxattr list % LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by % LocalWords: removexattr lremovexattr fremovexattr attributename lacl acl -% LocalWords: OBJ +% LocalWords: OBJ setfacl len any prefix separator options NUMERIC IDS SMART %%% Local Variables: %%% mode: latex %%% TeX-master: "gapil" %%% End: +% LocalWords: INDENT diff --git a/fileintro.tex b/fileintro.tex index cee6e9a..257f54d 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -121,13 +121,12 @@ ricerca parte dalla directory corrente (su cui torneremo in sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname relativo} \itindsub{pathname}{relativo}. -I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti -in ogni directory: il primo fa riferimento alla directory corrente e il -secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè -la directory che contiene il riferimento alla directory corrente; nel caso la -directory corrente coincida con la directory radice, allora il riferimento è a -se stessa. -\itindend{pathname} +I nomi ``\file{.}'' e ``\file{..}'' hanno un significato speciale e vengono +inseriti in ogni directory: il primo fa riferimento alla directory corrente e +il secondo alla directory \textsl{genitrice} (o \textit{parent directory}) +cioè la directory che contiene il riferimento alla directory corrente; nel +caso la directory corrente coincida con la directory radice, allora il +riferimento è a se stessa. \itindend{pathname} \subsection{I tipi di file} @@ -589,11 +588,11 @@ di \index{inode} inode. La nuova directory avrà allora un numero di riferimenti pari a due, in quanto è referenziata dalla directory da cui si era partiti (in cui è inserita la -nuova voce che fa riferimento a \file{img}) e dalla voce \file{.} -che è sempre inserita in ogni directory; questo vale sempre per ogni directory -che non contenga a sua volta altre directory. Al contempo, la directory da -cui si era partiti avrà un numero di riferimenti di almeno tre, in quanto -adesso sarà referenziata anche dalla voce \file{..} di \file{img}. +nuova voce che fa riferimento a \texttt{img}) e dalla voce ``\texttt{.}'' che +è sempre inserita in ogni directory; questo vale sempre per ogni directory che +non contenga a sua volta altre directory. Al contempo, la directory da cui si +era partiti avrà un numero di riferimenti di almeno tre, in quanto adesso sarà +referenziata anche dalla voce ``\texttt{..}'' di \texttt{img}. \subsection{Il filesystem \textsl{ext2}} -- 2.30.2