From fbaa0a5900dd5a65fd373dcbca8299ba0bc69493 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Wed, 9 May 2001 17:35:52 +0000 Subject: [PATCH] Tolto un po` di inglese e armonizzate alcune cose (con relativa creazione di cross reference) --- filedir.tex | 97 +++++++++++++++++++++++++++------------------------ fileintro.tex | 22 +++++++----- 2 files changed, 65 insertions(+), 54 deletions(-) diff --git a/filedir.tex b/filedir.tex index eaee409..6df35b2 100644 --- a/filedir.tex +++ b/filedir.tex @@ -22,33 +22,34 @@ medesimi nell'albero descritto brevemente in \ref{sec:fileintr_overview}; una directory comunque, come già specificato in \ref{sec:fileintr_vfs}, è solo un particolare tipo di file che contiene le informazioni che associano un nome al contenuto. Per questo, anche se è usuale parlare di ``file in una directory'' -in realtà una directory contiene solo dei riferimenti ai file, non i file -stessi. - -I nomi contenuti nelle directory sono chiamati componenti (\textit{file name - components}), un file può essere indicato rispetto alla directory corrente -semplicemente specificando il nome da essa contenuto. Una directory contiene -semplicemente un elenco di questi componenti, che possono corrispondere a un -qualunque oggetto del filesystem, compresa un'altra directory; l'albero viene -appunto creato inserendo directory in altre directory. - -Il nome di file generico è composto da una serie di \textsl{componenti} -separati da una \texttt{/} (in linux più \texttt{/} consecutive sono -considerate equivalenti ad una sola). Il nome completo di un file viene -usualmente chiamato \textit{pathname}, e anche se il manuale della glibc -depreca questo nome (poichè genererebbe confusione, dato che con \textit{path} -si indica anche un insieme di directory su cui effettuare una ricerca, come -quello in cui si cercano i comandi) l'uso è ormai così comune che è senz'altro -più chiaro dell'alternativa proposta. - -Il processo con cui si associa ad un pathname uno specifico file (cioè si -identifica l'inode a cui fare riferimento) è chiamato risoluzione del nome -(\textit{file name resolution} o \textit{pathname resolution}). -La risoluzione viene fatta esaminando il pathname da destra a sinistra e -localizzando ogni componente nella directory indicata dal componente -precedente: ovviamente perché il procedimento funzioni occorre che i -componenti indicati come directory esistano e siano effettivamente directory, -inoltre i permessi devono consentire l'accesso. +in realtà una directory contiene solo delle etichette per fare riferimento ai +file stessi. + +I manuale delle librerie del C chiama i nomi contenuti nelle directory +\textsl{componenti} (in inglese \textit{file name components}), noi li +chiameremo più semplicemente nomi. Un file può essere indicato rispetto alla +directory corrente semplicemente specificando il nome da essa contenuto. Una +directory contiene semplicemente un elenco di questi nomi, che possono +corrispondere a un qualunque oggetto del filesystem, compresa un'altra +directory; l'albero viene appunto creato inserendo directory in altre +directory. + +Il nome completo di file generico è composto da una serie di questi +\textsl{componenti} separati da una \texttt{/} (in linux più \texttt{/} +consecutive sono considerate equivalenti ad una sola). Il nome completo di un +file viene usualmente chiamato \textit{pathname}, e anche se il manuale della +glibc depreca questo nome (poichè genererebbe confusione, dato che con +\textit{path} si indica anche un insieme di directory su cui effettuare una +ricerca, come quello in cui si cercano i comandi) l'uso è ormai così comune +che è senz'altro più chiaro dell'alternativa proposta. + +Il processo con cui si associa ad un pathname uno specifico file è chiamato +risoluzione del nome (\textit{file name resolution} o \textit{pathname + resolution}). La risoluzione viene fatta esaminando il pathname da destra a +sinistra e localizzando ogni nome nella directory indicata dal nome +precedente: ovviamente perché il procedimento funzioni occorre che i nomi +indicati come directory esistano e siano effettivamente directory, inoltre i +permessi devono consentire l'accesso. Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice del processo; questa, a meno di un \textit{chroot} (su cui torneremo in @@ -59,7 +60,7 @@ equivale alla directory radice dell'albero (come descritto in cui torneremo più avanti in \ref{sec:filedir_work_dir}) ed il pathname è detto \textsl{relativo}. -I componenti \texttt{.} e \texttt{..} hanno un significato speciale e vengono +I nomi \texttt{.} e \texttt{..} hanno un significato speciale e vengono inseriti in ogni directory, il primo fa riferimento alla directory corrente e il secondo alla directory \textsl{genitore} (\textit{parent directory}) cioè la directory che contiene il riferimento alla directory corrente; nel caso @@ -72,8 +73,10 @@ questa sia la directory radice allora il riferimento Per capire fino in fondo le proprietà di files e directories in un sistema unix ed il funzionamento delle relative funzioni di manipolazione occorre una breve introduzione agli oggetti su cui è basato un filesystem unix; in -particolare si riprenderanno, approfondendoli, i concetti di \textit{inode} e -\textit{dentry} brevemente introdotti in \ref{sec:fileintr_vfs}. +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 +\ref{sec:fileintr_vfs}. \subsection{Il funzionamento di un filesystem} @@ -90,7 +93,7 @@ comuni di un qualunque filesystem standard unix. Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni partizione può contenere un filesystem; quest'ultimo è in genere strutturato -secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio aa +secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio a disposizione per i dati e le directory. \begin{figure}[htb] @@ -122,25 +125,28 @@ particolare fisici che contengono i dati e così via; le informazioni che la funzione \texttt{stat} fornisce provengono dall'\textit{inode}; dentro una directory si troverà solo il nome del file e il numero dell'\textit{inode} ad esso - associato, cioè quella che da qui in poi chiameremo una \textit{dentry}. + associato, cioè quella che da qui in poi chiameremo una \textsl{voce} + (traduzione approssimata dell'inglese \textit{directory entry}, che non + useremo anche per evitare confusione con le \textit{dentries} del kernel di + cui si parlava in \ref{sec:fileintr_vfs}). -\item Come mostrato in \curfig si possono avere più \textit{dentries} 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 +\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 effettivamente rimossi dal disco. Per questo la funzione per cancellare un file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del - file, ma si limita a eliminare la \textit{dentry} da una directory e + 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 \textit{dentry} 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 \texttt{ln} (che crea una nuova dentry per un file +\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 \texttt{ln} (che crea una nuova voce per un file esistente, con la funzione \texttt{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 creta una nuova + del file non deve essere spostato, viene semplicemente creata una nuova \textit{dentry} per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità in cui opera normalmente il comando \texttt{mv} attraverso la funzione \texttt{rename}). @@ -155,11 +161,11 @@ chiarezza abbiamo aggiunto dei numeri di 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 dentry che fa riferiemto a \texttt{textdir}) e dalla dentry \texttt{.} +nuova voce che fa riferimento a \texttt{textdir}) e dalla voce \texttt{.} che è sempre inserita in ogni directory; questo vale sempre per ogni directory che non contenga a sua volta altre directories. Al contempo la directory da cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto -adesso sarà referenziata anche dalla dentry \texttt{..} di \texttt{textdir}. +adesso sarà referenziata anche dalla voce \texttt{..} di \texttt{textdir}. \subsection{Le funzioni \texttt{link} e \texttt{unlink}} @@ -183,7 +189,8 @@ particolare preferenza rispetto agli altri. Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si suole chiamare questo tipo di associazione un collegamento diretto (o \textit{hard link}). Il prototipo della funzione, definita in -\texttt{unistd.h} è il seguente: +\texttt{unistd.h}, e le sue caratteritiche principali, come risultano dalla +man page, sono le seguenti: \begin{itemize} \item \texttt{int link(const char * oldname, const char * newname)} diff --git a/fileintro.tex b/fileintro.tex index bc08ca9..c010983 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -31,13 +31,15 @@ al Cap.~\ref{cha:intro_unix}. Partiamo allora da come viene strutturata nel sistema la disposizione dei file: per potervi accedere il kernel usa una apposita interfaccia che permetta di strutturare l'informazione tenuta sullo spazio grezzo disponibile sui -dischi, cioè quello che si chiama un \textit{filesystem}. +dischi, cioè quello che si chiama un \textit{filesystem} (useremo per brevità +questo nome al posto della più prolissa traduzione italiana sistema di file). Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati memorizzati all'interno del disco stesso, strutturando l'informazione in files -e directory. Per poter accedere ai file contenuti in un disco occorrerà -perciò attivare il filesystem, questo viene fatto \textsl{montando} il disco -(o la partizione del disco). +e directory (su questo aspetto torneremo con maggiori dettagli in +\ref{sec:filedir_filesystem}). Per poter accedere ai file contenuti in un +disco occorrerà perciò attivare il filesystem, questo viene fatto +\textsl{montando} il disco (o la partizione del disco). %In generale un filesystem piazzerà opportunamente sul disco dei blocchi di %informazioni riservate che tengono conto degli inodes allocati, di quelli @@ -127,8 +129,9 @@ una struttura di tipo \texttt{file} in cui viene inserito un puntatore alla dentry e una struttura \verb|f_ops| che contiene i puntatori ai metodi che implementano le operazioni disponibili sul file. In questo modo i processi in user space possono accedere alle operazioni attraverso detti metodi, che -saranno diversi a seconda del tipo di file (o dispositivo) aperto. Un elenco -delle operazioni disponibili è riportato in \ntab. +saranno diversi a seconda del tipo di file (o dispositivo) aperto (su questo +torneremo in dettaglio in \ref{sec:fileunix_fd}). Un elenco delle operazioni +previste dal kernel è riportato in \ntab. \begin{table}[htb] \centering @@ -173,8 +176,9 @@ diversi filesystem (come quelli usati da Windows o MacOs) In unix è implementata da qualunque filesystem standard una forma elementare (ma adatta alla maggior parte delle esigenze) di controllo di accesso ai -files. Torneremo sull'argomento in dettaglio più avanti, qui ci limitiamo ad -una introduzione dei concetti essenziali. +files. Torneremo sull'argomento in dettaglio più avanti (vedi +\ref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei +concetti essenziali. Si tenga conto poi che quanto diremo è vero solo per filesystem di tipo Unix, e non è detto che sia applicabile (ed infatti non è vero per il filesystem di @@ -184,7 +188,7 @@ di controllo di accesso molto pi Ad ogni file Unix associa sempre l'utente che ne è proprietario (il cosiddetto \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli uid e -gid spiegato in Sez.~\ref{sec:intro_usergroup}, e un insieme di permessi che +gid accennato in Sez.~\ref{sec:intro_usergroup}, e un insieme di permessi che sono divisi in tre classi, e cioè attribuiti rispettivamente al proprietario, a qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli altri utenti. -- 2.30.2