Tolto un po` di inglese e armonizzate alcune cose (con relativa creazione
[gapil.git] / filedir.tex
index f68576f0cb859b5d5ea18e4c03aaffe3411b0e2c..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''
 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]
@@ -100,67 +103,69 @@ disposizione per i dati e le directory.
   \label{fig:filedir_disk_filesys}
 \end{figure}
 
   \label{fig:filedir_disk_filesys}
 \end{figure}
 
-Se si va ad esaminare come è strutturata l'informazione all'interno del
-filesystem (tralasciando le parti che non riguardano direttamente la gestione
-di file e directory come il super-block) avremo una situazione del tipo di
-quella esposta in \nfig.
-
+Se si va ad esaminare come è strutturata l'informazione all'interno di un
+singolo filesystem (tralasciando le parti connesse alla strutturazione e al
+funzionamento del filesystem stesso come il super-block) avremo una situazione
+del tipo di quella esposta in \nfig.
 \begin{figure}[htb]
   \centering
   
   \caption{Organizzazione di un filesystem}
   \label{fig:filedir_filesys_detail}
 \end{figure}
 \begin{figure}[htb]
   \centering
   
   \caption{Organizzazione di un filesystem}
   \label{fig:filedir_filesys_detail}
 \end{figure}
-
-
-Quanto mostrato in \curfig\ mette in evidenza alcune caratteristiche di un 
-filesystem unix su cui è bene porre attenzione in quanto sono fondamentali per
-capire il funzionamento delle funzioni che manipolano i file e le directory su
-cui torneremo fra poco; in particolare è opportuno ricordare sempre che:
+da questa figura si evidenzano alcune caratteristiche su cui è bene porre
+attenzione in quanto sono fondamentali per capire il funzionamento delle
+funzioni che manipolano i file e le directory su cui torneremo fra poco; in
+particolare è opportuno ricordare sempre che:
 
 \begin{itemize}
   
 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
   tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
   fisici che contengono i dati e così via; le informazioni che la funzione
 
 \begin{itemize}
   
 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
   tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
   fisici che contengono i dati e così via; le informazioni che la funzione
-  \texttt{stat} fornisce provengono dall'inode; dentro una directory si
-  troverà solo il nome del file e il numero dell'inode ad esso associato, cioè
-  una \textit{dentry}.
+  \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 \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ù dentries che puntano allo
-  stesso inode. Ogni 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 il file può essere cancellato. Per questo in
-  generale non esiste una funzione che cancelli un file, ma solo la funzione
-  \texttt{unlink} che si chiama così proprio perché che toglie un riferimento
-  da una directory (cancellando la dentry), il che non comporta
-  automaticamente pure la eliminazione dei blocchi sul disco.
+\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 relativa voce da una directory e
+  decrementare il numero di riferimenti nell'\textit{inode}.
+  
+\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 Siccome il numero di inode nella dentry si riferisce ad un inode nello
-  stesso filesystem non ci può essere una directory che contiene riferimenti
-  ad inodes relativi ad altri filesystem, questo limita l'uso del comando
-  \texttt{ln} (che crea una nuova dentry 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
 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
-  del file non deve essere spostato, ma basta creare una nuova dentry per
-  l'inode in questione rimuovendo la vecchia (che è la modalità in cui opera
-  normalmente il comando \texttt{mv} attraveso la funzione \texttt{rename}).
+  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}).
 
 \end{itemize}
 
 
 \end{itemize}
 
-Infine è bene avere presente che esiste un numero di riferimenti anche per le
-directories, se a partire dalla situazione mostrata in \curfig\ creiamo una
-nuova directory \texttt{textdir} avremo una situazione come quella in \nfig,
-dove per chiarezza abbiamo aggiunto dei numeri di inode.
+Infine è bene avere presente che essendo file pure loro, esiste un numero di
+riferimenti anche per le directories; per cui se ad esempio a partire dalla
+situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir}
+nella directory corrente avremo una situazione come quella in \nfig, dove per
+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}}
@@ -173,31 +178,81 @@ ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
 per fare questa operazione.
 
 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
 per fare questa operazione.
 
-Come si è appena visto l'accesso al contenuto di un file su disco avviene
-attraverso il suo \textit{inode}, e il nome che si trova in una directory è
-solo una etichetta associata ad un puntatore a detto 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.
+Come si è appena detto l'accesso al contenuto di un file su disco avviene
+attraverso il suo inode, e il nome che si trova in una directory è solo una
+etichetta associata ad un puntatore a detto 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.
 
 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
 suole chiamare questo tipo di associazione un collegamento diretto (o
 
 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}).  La creazione di un nuovo link diretto non copia il
-contenuto del file, ma si limita ad aumentare di uno il numero di referenze al
-file aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
-essere così richiamato in diverse directory.
-
+\textit{hard link}).  Il prototipo della funzione, definita in
+\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)}
   
-  Crea un nuovo link diretto al file indicato da \texttt{oldname} dandogli
-  nome \texttt{newname}.
+  Crea un nuovo collegamento diretto al file indicato da \texttt{oldname}
+  dandogli nome \texttt{newname}.
   
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
-  di errore. La variabile \texttt{errno} viene settata secondo i codici di
-  errore standard di accesso ai files (trattati in dettaglio in
-  \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
+  di errore. La variabile \texttt{errno} viene settata secondo i seguenti
+  codici di errore:
+
+  \begin{itemize}
+  \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
+    stesso filesystem.
+  \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
+    \texttt{newname} non supporta i link diretti.
+  \item \texttt{EACCESS} 
+    Non c'è il permesso di scrittura per la directory in cui si vuole creare
+    il nuovo link.
+  \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
+    già.
+  \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
+    numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
+    \ref{sec:xxx_limits}.
+  \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
+    non può essere ampliata.
+  \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
+    su un filesystem montato readonly.
+  \end{itemize}
+\end{itemize}
+
+La creazione di un nuovo collegamento diretto non copia il contenuto del file,
+ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
+nuovo nome ai precedenti. Si noti che uno stesso file può essere così
+richiamato in diverse directory.
+Per quanto dicevamo in \ref{sec:filedir_filesystem} la creazione del
+collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
+filesytem; inoltre il filesystem deve supportare i collegamenti diretti (non è
+il caso ad esempio del filesystem \texttt{vfat} di windows).
+
+La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
+ma solo l'amministratore è in grado di creare un collegamento diretto ad
+un'altra directory, questo lo si fa perché in questo caso è possibile creare
+dei cerchi nel filesystem (vedi \ref{sec:filedir_symlink}) che molti programmi
+non sono in grado di gestire e la cui rimozione diventa estremamente
+complicata (in genere occorre far girare il programma \texttt{fsck} per
+riparare il filesystem).
+
+
+La rimozione di un file (o più precisamente di una sua dentry) si effettua con
+la funzione \texttt{unlink}; il suo prototipo, definito in \texttt{unistd.h} è
+il seguente:
+
+\begin{itemize}
+\item \texttt{int unlink(const char * filename)}
+  
+  Cancella il nome specificato dal pathname nella relativa directory e
+  decrementa il numero di riferimenti nel relativo inode.
+  
+  La funzione restituisce zero in caso di successo e -1 per un errore, in caso
+  di errore. La variabile \texttt{errno} viene settata secondo i seguenti
+  codici di errore:
 
   \begin{itemize}
   \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
 
   \begin{itemize}
   \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
@@ -219,6 +274,19 @@ essere cos
   \end{itemize}
 \end{itemize}
 
   \end{itemize}
 \end{itemize}
 
+Per cancellare 
+
+
+
+
+
+Una delle caratteristiche di queste funzioni è che la creazione/rimozione
+della nnome dalla directory e l'incremento/decremento del numero di
+riferimenti nell'inode deve essere una operazione atomica (cioè non
+interrompibile da altri) processi, per questo entrambe queste funzioni sono
+realizzate tramite una singola system call.
+
+
 
 
 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
 
 
 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
@@ -251,8 +319,8 @@ funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
 alle informazioni del link invece che a quelle del file a cui esso fa
 riferimento.
 
 alle informazioni del link invece che a quelle del file a cui esso fa
 riferimento.
 
-Le funzioni per operare sui link sono le seguenti, esse sono tutte dichiarate
-nell'header file \texttt{unistd.h}.
+Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
+dichiarate nell'header file \texttt{unistd.h}.
 
 \begin{itemize}
 \item \texttt{int symlink(const char * oldname, const char * newname)}
 
 \begin{itemize}
 \item \texttt{int symlink(const char * oldname, const char * newname)}
@@ -419,15 +487,13 @@ per cambiare directory di lavoro.
 
 
 
 
 
 
+
+
+
 \section{La manipolazione delle caratteristiche dei files}
 \label{sec:filedir_infos}
 
 
 \section{La manipolazione delle caratteristiche dei files}
 \label{sec:filedir_infos}
 
 
-Si ricordi che in unix non esistono i tipi di file e che non c'è nessun
-supporto per le estensioni come parte del filesystem. Ciò non ostante molti
-programmi adottano delle convenzioni per i nomi dei file, ad esempio il codice
-C normalmente si mette in file con l'estensione .c, ma questa è, appunto, solo
-una convenzione.
 
 
 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
 
 
 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}