Tolto un po` di inglese e armonizzate alcune cose (con relativa creazione

di cross reference)

diff --git a/filedir.tex b/filedir.tex
index eaee40933274723ab566639c41682f61a0438710..6df35b229a497155c8f74bda6a5c3311dd971353 100644 (file)
--- 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''
 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
 
 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}.
 
 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
 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
 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}
 
 
 \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
 
 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]
 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
   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
   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}.
   
   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
   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}).
   \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
 
 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
 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}}
 
 
 \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
 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)}
   
 \begin{itemize}
 \item \texttt{int link(const char * oldname, const char * newname)}
   

diff --git a/fileintro.tex b/fileintro.tex
index bc08ca9a92f230fbd32f3e232ea8cf3c89e44ddc..c0109833ee15b7258baeb95b84935a84e8efc95f 100644 (file)
--- 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
 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
 
 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
 
 %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
 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
 
 \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
 
 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
 
 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
 
 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.
 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.