Tolto un po` di inglese e armonizzate alcune cose (con relativa creazione
[gapil.git] / filedir.tex
index eaee40933274723ab566639c41682f61a0438710..6df35b229a497155c8f74bda6a5c3311dd971353 100644 (file)
@@ -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)}