Risistemati un sacco di riferiementi, e la riorganizzazione della parte

[gapil.git] / fileintro.tex

\chapter{I files: l'architettura}
\label{cha:files_intro}
 
Uno dei concetti fondamentali della architettura di unix è il cosiddetto
\textit{everything is a file}, cioè il fatto che l'accesso ai vari dispositivi
di input/output del computer viene effettuato attraverso un'interfaccia
astratta che tratta le periferiche allo stesso modo degli usuali file di dati.

Questo significa che si può accedere a qualunque periferica del computer,
dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
cosiddetti file di dispositivo (i \textit{device files}). Questi sono dei file
speciali agendo sui quali i programmi possono leggere, scrivere e compiere
operazioni direttamente sulle periferiche, usando le stesse funzioni che si
usano per i normali file di dati.

In questo capitolo forniremo un'introduzione all'architettura della gestione
dei file, sia nelle sue caratteristiche generiche comuni a tutti gli unix, che
nelle particolarità che ha la specifica implementazione usata da Linux. Al
contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le
varie caratteristiche distintive.

\section{L'organizzazione di files e directories}
\label{sec:fileintr_organization}

Il primo passo nella trattazione dell'achitettura della gestione dei file in
un sistema unix-like, è quello dell'esame di come essi vengono organizzati e
di quale è la struttura che hanno all'interno del sistema.


\subsection{La struttura di files e directory}
\label{sec:fileintr_filedir_struct}

Partiamo allora da come viene strutturata nel sistema la disposizione dei
file: per potervi accedere il kernel usa una apposita interfaccia che permetta
di accedere all'informazione tenuta sullo spazio grezzo disponibile sui
dischi, cioè quello che si chiama un \textit{filesystem}\footnote{useremo per
  brevità questo nome al posto della più prolissa traduzione italiana sistema
  di file}, che descriviremo in dettaglio in \secref{sec:fileintr_vfs}.

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).

%In generale un filesystem piazzerà opportunamente sul disco dei blocchi di
%informazioni riservate che tengono conto degli inodes allocati, di quelli
%liberi, e delle posizioni fisiche su disco dei dati contenuti nei files, per

In unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
file vengono tenuti all'interno di un unico albero la cui radice (la directory
di \textit{root}) viene montata all'avvio. Pertanto un file viene identificato
dall'utente usando quello che viene chiamato \textit{pathname}, cioè il
percorso che si deve fare per accedere al file.

Dopo la fase di inizializzazione il kernel riceve dal boot loader
l'indicazione di quale dispositivo contiene il filesystem da usare come punto
di partenza e questo viene montato come radice dell'albero (cioè nella
directory \texttt{/}); tutti gli ulteriori dischi devono poi essere inseriti
nell'albero utilizzando opportune subdirectory.

Alcuni filesystem speciali (come \texttt{/proc} che contiene un'interfaccia ad
alcune strutture interne del kernel) sono generati automaticamente dal kernel
stesso, ma anche essi devono essere montati all'interno dell'albero.

All'interno dello stesso albero si potranno poi inserire anche gli altri
oggetti visti attraverso l'interfaccia che manipola i files come le FIFO, i
link, i socket e gli stessi i file di dispositivo (questi ultimi, per
convenzione, sono inseriti nella directory \texttt{/dev}).

L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
medesimi nell'albero descritto in precedenza; una directory comunque, come già
specificato in \secref{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 delle etichette per fare riferimento ai file stessi.

I manuale delle glibc 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
seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed
equivale alla directory radice dell'albero (come descritto in
\secref{sec:fileintr_organization}): in questo caso si parla di un pathname
\textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
cui torneremo più avanti in \secref{sec:filedir_work_dir}) ed il pathname è
detto \textsl{relativo}.

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
questa sia la directory radice allora il riferimento è a se stessa.


% \subsection{Il controllo di accesso}
% \label{sec:fileintr_access_ctrl}


\subsection{I tipi di files}
\label{sec:fileintr_file_types}

Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
sono implementati come oggetti del \textit{Virtual File System} e sono
presenti in tutti i filesystem unix-like utilizzabili con Linux. L'elenco dei
vari tipi di file definiti dal Virtual File System è riportato in \ntab.

Si tenga ben presente che questa classificazione non ha nulla a che fare con
la classificazione sui tipi di file (che in questo caso sono sempre file di
dati) in base al loro contenuto, o tipo di accesso.

 
\begin{table}[htb]
  \begin{center}
    \begin{tabular}[c]{l l p{7cm}}
    \multicolumn{2}{c}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
    \hline
      \textit{regular file} & \textsl{file normale} &
      un file che contiene dei dati (l'accezione normale di file) \\
      \textit{directory} & \textsl{cartella o direttorio} &
      un file che contiene una lista di nomi associati a degli inodes \\
      \textit{symbolic link} & \textsl{collegamento simbolico} &
      un file che contiene un riferimento ad un altro file/directory \\
      \textit{char device} & \textsl{dispositivo a caratteri} &
      un file che identifica una periferica ad accesso sequenziale \\
      \textit{block device} & \textsl{dispositivo a blocchi} &
      un file che identifica una periferica ad accesso diretto \\
      \textit{fifo} & \textsl{tubo} &
      un file speciale che identifica una linea di comunicazione software
      (unidirezionale) \\
      \textit{socket} & \textsl{manicotto} &
      un file speciale che identifica una linea di comunicazione software
      (bidirezionale) \\
    \hline
    \end{tabular}
    \caption{Tipologia dei file definiti nel VFS}
    \label{tab:fileintr_file_types}
  \end{center}
\end{table}

Una delle differenze principali con altri sistemi operativi (come il VMS o
Windows) è che per Unix tutti i file di dati sono identici e contengono un
flusso continuo di bytes; non esiste cioè differenza per come vengono visti
dal sistema file di diverso contenuto o formato (come nel caso di quella fra
file di testo e binari che c'è in Windows) né c'è una strutturazione a record
per il cosiddetto ``accesso diretto'' come nel caso del VMS.
%  (con i kernel
% della serie 2.4 è disponibile una forma di accesso diretto ai dischi il
% \textit{raw access} che però non ha nulla a che fare con questo).

Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
codificata in maniera diversa da Windows o MacIntosh, in particolare il fine
riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
(\verb|\r|) del mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
problemi qualora nei programmi si facciano assunzioni sul terminatore della
riga.


\subsection{Le due interfacce ai file}
\label{sec:fileintr_io_api}

In unix le modalità di accesso ai file e le relative interfacce di
programmazione sono due, basate su due diversi meccanismi con cui è possibile
accedere al loro contenuto.

La prima è l'interfaccia standard di unix, quella che il manuale delle glibc
chiama interfaccia dei descrittore di file (o \textit{file descriptor}).  È
un'interfaccia specifica di unix e provvede un accesso non bufferizzato.

L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
direttamente le system call del kernel (in realtà il kernel effettua al suo
interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
dispositivi); i file descriptors sono rappresentati da numeri interi (cioè
semplici variabili di tipo \texttt{int}).  L'interfaccia è definita
nell'header \texttt{unistd.h}.

La seconda interfaccia è quella che il manuale della glibc chiama degli
\textit{stream}, essa provvede funzioni più evolute e un accesso bufferizzato
(controllato dalla implementazione fatta dalle librerie del C).  Questa è
l'interfaccia standard usata dal linguaggio C e perciò si trova anche su tutti
i sistemi non Unix. Gli stream sono oggetti complessi e sono rappresentati da
puntatori ad un opportuna struttura definita dalle librerie del C, si accede
ad essi sempre in maniera indiretta utilizzando il tipo \texttt{FILE *}.
L'interfaccia è definita nell'header \texttt{stdio.h}.

Entrambe le interfacce possono essere usate per l'accesso ai file come agli
altri oggetti del VFS (pipes, socket, device), ma per poter accedere alle
operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre
usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
devono essere usati i file descriptor se si vuole ricorrere a modalità
speciali di I/O come il polling o il non-bloccante (vedi
\secref{sec:file_xxx}).

Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
dei file descriptor, che tratta tutti i file nello stesso modo, con
l'eccezione di poter scegliere tra diversi stili di bufferizzazione.  Il
maggior vantaggio degli stream è che l'interfaccia per le operazioni di
input/output è enormemente più ricca di quella dei file descriptor, che
provvedono solo funzioni elementari per la lettura/scrittura diretta di
blocchi di bytes.  In particolare gli stream dispongono di tutte le funzioni
di formattazione per l'input e l'output adatte per manipolare anche i dati in
forma di linee o singoli caratteri.

In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
standard di unix, è sempre possibile estrarre il file descriptor da uno stream
ed eseguirvi operazioni di basso livello, o associare in un secondo tempo uno
stream ad un file descriptor.

In generale, se non necessitano specificatamente le funzionalità di basso
livello, è opportuno usare sempre gli stream per la loro maggiore portabilità
essendo questi ultimi definiti nello standard ANSI C; l'interfaccia con i file
descriptor invece segue solo lo standard POSIX.1 dei sistemi unix ed è
pertanto di portabilità più limitata.

\subsection{Caratteristiche specifiche dei file in unix}
\label{sec:fileint_unix_spec}

Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
specifiche di Unix che devono essere tenute in conto nell'accesso ai file. È
infatti normale che più processi o programmi possano accedere
contemporaneamente allo stesso file e devono poter eseguire le loro operazioni
indipendentemente da quello che fanno gli altri processi.

Per questo motivo le strutture usate per all'accesso ai file sono relative al
processo che effettua l'accesso.  All'apertura di ogni file infatti viene
creata all'interno del processo una apposita struttura in cui sono memorizzati
tutti gli attributi del medesimo, che viene utilizzata per tutte le
operazioni. Questa è una struttura che resta locale al processo stesso; in
questo modo processi diversi possono usare le proprie strutture locali per
accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
indipendente.

Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
successiva. Essa è rappresentata da un numero intero che indica il numero di
bytes dall'inizio del file, che viene (a meno che non si apra il file in
append) inizializzato a zero all'apertura del medesimo.

Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
ogni processo avrà la sua posizione corrente nel file, che non sarà
influenzata da quello che altri processi possono fare. Anzi, aprire un file
significa appunto creare ed inizializzare una tale struttura, per cui se si
apre due volte lo stesso file all'interno dello stesso processo, si otterranno
due file descriptor o due stream che avranno ancora una posizione corrente nel
file assolutamente indipendente.

Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
accesso è un riferimento all'inode del file, pertanto anche se il file viene
cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
in dettaglio in \secref{sec:fileintr_link}) aprire un file provvisorio per
cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
saranno disponibili per tutto il tempo in cui il processo è attivo.

Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
esaminando in dettaglio come tutto ciò viene realizzato.

Si ricordi infine 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.



\section{L'architettura della gestione dei file}
\label{sec:fileintro_architecture}

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 sulla gestione dei medesimo e sugli oggetti su cui è basato
un filesystem unix. In particolare occorre tenere presente dov'è che si situa
la divisione fondamentale fra kernel space e user space che tracciavamo al
\capref{cha:intro_unix}.

In questa sezione esamineremo allora come viene implementato l'accesso ai
files in Linux, come il kernel gestisce i vari filesystem, descrivendo poi in
maniera un po' più dettagliata il filesystem standard di Linux,
l'\texttt{ext2}, come esempio di un filesystem unix-like.


% in 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 \secref{sec:fileintr_vfs}.

\subsection{Il \textit{virtual filesystem} di Linux}
\label{sec:fileintr_vfs}

% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
% files.  L'argomento è abbastanza ``esoterico'' e questa sezione può essere
% saltata ad una prima lettura; è bene però tenere presente che vengono
% introdotti qui alcuni termini che potranno comparire in seguito, come
% \textit{inode}, \textit{dentry}, \textit{dcache}.

In Linux il concetto di \textit{everything is a file} è stato implementato
attraverso il \textit{virtual filesystem} (da qui in avanti VFS) che è
l'interfaccia che il kernel rende disponibile ai programmi in user space
attraverso la quale vengono manipolati i files; esso provvede un livello di
indirezione che permette di collegare le operazioni di manipolazione sui files
alle operazioni di I/O e gestisce l'organizzazione di questi ultimi nei vari
modi in cui diversi filesystem la effettuano, permettendo la coesistenza
di filesystem differenti all'interno dello stesso albero delle directory

Quando un processo esegue una system call che opera su un file il kernel
chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
manipolazioni sulle strutture generiche e ridirigendo la chiamata alla
opportune routine del filesystem specifico a cui si fa riferimento, saranno
queste a chiamare le funzioni di piu basso livello che eseguono le operazioni
di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig.

\begin{figure}[htb]
  \centering
  
  \caption{Schema delle operazioni del VFS}
  \label{fig:fileintro_VFS_scheme}
\end{figure}

La funzione più importante implementata dal VFS è la system call \texttt{open}
che permette di aprire un file. Dato un pathname viene eseguita una ricerca
dentro la \textit{directory entry cache} (in breve \textit{dcache}),
una tabella di hash che contiene tutte le \textit{directory entry} (in breve
\textit{dentry}) che permette di associare in maniera rapida ed efficiente il
pathname a una specifica dentry.

Una singola dentry contiene in genere il puntatore ad un \textit{inode};
quest'ultimo è la struttura base che sta sul disco e che identifica un singolo
oggetto del VFS sia esso un file ordinario, una directory, una FIFO, un file
di dispositivo, o una qualsiasi altra cosa che possa essere rappresentata dal
VFS (sui tipi di ``files'' possibili torneremo in seguito). A ciascuno di essi
è associata pure una struttura che sta in memoria, e che oltre alle
informazioni sullo specifico file contiene pure il riferimento alle funzioni
(i \textsl{metodi}) da usare per poterlo manipolare.

Le dentries ``vivono'' in memoria e non vengono mai salvate su disco, vengono
usate per motivi di velocità, gli inodes invece stanno su disco e vengono
copiati in memoria quando serve, ed ogni cambiamento viene copiato
all'indietro sul disco, gli inodes che stanno in memoria sono inodes del VFS
ed è ad essi che puntano le singole dentry.

La dcache costituisce perciò una sorta di vista completa di tutto l'albero dei
files, ovviamente per non riempire tutta la memoria questa vista è parziale
(la dcache cioè contiene solo le dentry per i file per i quali è stato
richiesto l'accesso), quando si vuole risolvere un nuovo pathname il VFS deve
creare una nuova dentry e caricare l'inode corrispondente in memoria. 

Questo procedimento viene eseguito dal metodo \texttt{lookup()} dell'inode
della directory che contiene il file; questo viene installato nelle relative
strutture in memoria quando si effettua il montaggio lo specifico filesystem
su cui l'inode va a vivere.

Una volta che il VFS ha a disposizione la dentry (ed il relativo inode)
diventa possibile accedere alle varie operazioni sul file come la
\texttt{open} per aprire il file o la \texttt{stat} per leggere i dati
dell'inode e passarli in user space.

L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
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 (su questo
torneremo in dettaglio in \secref{sec:fileunix_fd}). Un elenco delle operazioni
previste dal kernel è riportato in \ntab.

\begin{table}[htb]
  \centering
  \begin{tabular}[c]{c p{7cm}}
    \textbf{funzione} & \textbf{operazione} \\
    \hline
    \textit{open}    & apre il file \\
    \textit{read}    & legge dal file \\
    \textit{write}   & scrive sul file \\ 
    \textit{llseek}  & sposta la posizione corrente sul file \\
    \textit{ioctl}   & accede alle operazioni di controllo 
                       (tramite la \texttt{ioctl})\\
    \textit{readdir} & per leggere il contenuto di una directory \\
    \textit{poll}    & \\
    \textit{mmap}    & chiamata dalla system call \texttt{mmap}. 
                       mappa il file in memoria\\
    \textit{release} & chiamata quando l'ultima referenza a un file 
                       aperto è chiusa\\
    \textit{fsync}   & chiamata dalla system call \texttt{fsync} \\
    \textit{fasync}  & chiamate da \texttt{fcntl} quando è abilitato 
                       il modo asincrono per l'I/O su file. \\
    \hline
  \end{tabular}
  \caption{Operazioni sui file definite nel VFS.}
  \label{tab:fileintr_file_operations}
\end{table}

In questo modo per ciascun file diventano utilizzabili una serie di operazioni
(non è dette che tutte siano disponibili), che costituiscono l'interfaccia
astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad
utilizzare la opportuna routine dichiarata in \verb|f_ops| appropriata al tipo
di file in questione. 

Così sarà possibile scrivere sulla porta seriale come su un file di dati
normale; ovviamente certe operazioni (nel caso della seriale ad esempio la
\textit{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
diversi filesystem (come quelli usati da Windows o MacOs) è immediato e
(relativamente) trasparente per l'utente ed il programmatore.


\subsection{Il funzionamento di un filesystem unix}
\label{sec:fileintr_filesystem}

Come già accennato in \secref{sec:fileintr_organization} Linux (ed ogni unix
in generale) organizza i dati che tiene su disco attraverso l'uso di un
filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è
quella di poter supportare grazie al VFS una enorme quantità di filesystem
diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
daremo una descrizione a grandi linee che si adatta alle caratteristiche
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 a
disposizione per i dati e le directory.

\begin{figure}[htb]
  \centering
  
  \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
  \label{fig:fileintr_disk_filesys}
\end{figure}

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:fileintr_filesys_detail}
\end{figure}
da questa figura si evidenziano 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{enumerate}
  
\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'\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 \secref{sec:fileintr_vfs}).
  
\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 Quando si cambia nome ad un file senza cambiare filesystem il contenuto
  del file non deve essere spostato, viene semplicemente creata una nuova voce
  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{enumerate}

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
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 voce \texttt{..} di \texttt{textdir}.


\subsection{Le funzioni \texttt{link} e \texttt{unlink}}
\label{sec:fileintr_link}

Una delle caratteristiche usate quando si opera con i file è quella di poter
creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
stesso file accedendovi da directory diverse. Questo è possibile anche in
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.

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
\textit{hard link}).  Il prototipo della funzione e le sue caratteristiche
principali, come risultano dalla man page, sono le seguenti:
\begin{prototype}{unistd.h}
{int link(const char * oldpath, const char * newpath)}
  Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath}
  dandogli nome \texttt{newpath}.
  
  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{errlist}
  \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
    stesso filesystem.
  \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e
    \texttt{newpath} non supporta i link diretti o è una directory.
  \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori
    dello spazio di indirizzi del processo.
  \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
    per attraversare le directories), vedi \secref{sec:filedir_access_control}
    per i dettagli.
  \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo.
  \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath}
    non esiste o è un link simbolico spezzato.
  \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath}
    non è una directory.
  \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
    completare l'operazione. 
  \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è
    su un filesystem montato readonly.
  \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di
    già.
  \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il
    numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
    \secref{sec:xxx_limits}).
  \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione
    di \texttt{oldpath} o \texttt{newpath}.
  \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha
    spazio per ulteriori voci.
  \item \texttt{EIO} c'è stato un errore di input/output.
  \end{errlist}
\end{prototype}

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 \secref{sec:fileintr_filesystem} la creazione del
collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
filesystem; 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 circoli nel filesystem (vedi \secref{sec:fileintr_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); data la sua pericolosità in Linux questa
caratteristica è stata disabilitata, e la funzione restituisce l'errore
\texttt{EPERM}.

La rimozione di un file (o più precisamente della voce che lo referenzia) si
effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:

\begin{prototype}{unistd.h}{int unlink(const char * pathname)}
  Cancella il nome specificato dal pathname nella relativa directory e
  decrementa il numero di riferimenti nel relativo inode. Nel caso di link
  simbolico cancella il link simbolico; nel caso di socket, fifo o file di
  dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
  uno di questi oggetti possono continuare ad utilizzarlo.
  
  La funzione restituisce zero in caso di successo e -1 per un errore, nel
  qual caso il file non viene toccato. La variabile \texttt{errno} viene
  settata secondo i seguenti codici di errore:
  \begin{errlist}
  \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o
    per attraversare le directories), vedi \secref{sec:filedir_access_control}
    per i dettagli.
  \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory
    (valore specifico ritornato da linux che non consente l'uso di
    \texttt{unlink} con le directory, e non conforme allo standard POSIX, che
    prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia
    consnetita o il processo non abbia privilegi sufficienti).
  \item \texttt{EFAULT} la stringa
    passata come parametro è fuori dello spazio di indirizzi del processo.
  \item \texttt{ENAMETOOLONG} il pathname troppo lungo.
  \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link
    simbolico spezzato.
  \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory.
  \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory.
  \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
    completare l'operazione. 
  \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola
    lettura.
  \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del
    pathname.
  \item \texttt{EIO} errore di input/output.
  \end{errlist}
\end{prototype}

Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
il diritto di esecuzione sulla directory che la contiene (torneremo in
dettaglio sui permessi e gli attributi fra poco), se inoltre lo
\textit{sticky} bit è settato occorrerà anche essere proprietari del file o
proprietari della directory (o root, per cui nessuna delle restrizioni è
applicata).

Una delle caratteristiche di queste funzioni è che la creazione/rimozione
della nome 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.

Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
  count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
questo però si aggiunge una altra condizione, e cioè che non ci siano processi
che abbiano detto file aperto. Come accennato 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 aprire il file e chiamare
\texttt{unlink} subito dopo.

\subsection{Le funzioni \texttt{remove} e \texttt{rename}}
\label{sec:fileintr_remove}

Al contrario di quanto avviene con altri unix in Linux non è possibile usare
\texttt{unlink} sulle directory, per cancellare una directory si può usare la
funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
per cancellare un file o una directory (e funziona anche per i sistemi che non
supportano i link diretti), che per i file è identica alla \texttt{unlink} e
per le directory è identica alla \texttt{rmdir}:

\begin{prototype}{stdio.h}{int remove(const char *pathname)}
  Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e
  \texttt{rmdir} per le directory.
  
  La funzione restituisce zero in caso di successo e -1 per un errore, nel
  qual caso il file non viene toccato. Per i codici di errori vedi quanto
  riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}.
\end{prototype}

Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il
vantaggio nell'uso di questa funzione al posto della chiamata successiva di
\texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in
questo modo non c'è la possibilità che un processo che cerchi di accedere al
nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante.

\begin{prototype}{stdio.h}
{int rename(const char *oldpath, const char *newpath)}
  Rinomina un file, spostandolo fra directory diverse quando richiesto.

  La funzione restituisce zero in caso di successo e -1 per un errore, nel
  qual caso il file non viene toccato. La variabile \texttt{errno} viene
  settata secondo i seguenti codici di errore:
  \begin{errlist} 
  \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre
    \texttt{oldpath} non è una directory. 
  \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
    stesso filesystem. 
  \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e
    non vuota.
  \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da
    parte di qualche processo (come directory di lavoro o come root) o del
    sistema (come mount point).
  \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di
    \texttt{oldpath} o più in generale si è cercato di creare una directory
    come sottodirectory di se stessa.
  \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link
    consentiti o è una directory e la directory che contiene \texttt{newpath}
    ha già il massimo numero di link. 
  \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory
    o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una
    directory.
  \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello
    spazio di indirizzi del processo.
  \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
    cui si vuole creare il nuovo link o una delle directory del pathname non
    consente la ricerca (permesso di esecuzione).
  \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o
    \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non
    consentono rispettivamente la cancellazione e la creazione del file, o il
    filesystem non supporta i link.
  \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo.
  \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
    simbolico spezzato.
  \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
    completare l'operazione. 
  \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura.
  \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
    pathname.
  \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la
    nuova voce. 
  \end{errlist}    
\end{prototype}

\subsection{I link simbolici}
\label{sec:fileintr_symlink}

Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
tipo unix.  Inoltre 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,
come avviene in altri sistemi operativi, dei file che contengono il
semplicemente il riferimento ad un altro file (o directory). In questo modo è
possibile effettuare link anche attraverso filesystem diversi e a directory, e
pure a file che non esistono ancora.

Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
lettura del contenuto del medesimo e l'applicazione della funzione al file
specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
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.

Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
dichiarate nell'header file \texttt{unistd.h}.

\begin{prototype}{unistd.h}
{int symlink(const char * oldname, const char * newname)}
  Crea un nuovo link simbolico 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
  di errore. La variabile \texttt{errno} viene settata secondo i codici di
  errore standard di accesso ai files (trattati in dettaglio in
  \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
  \begin{errlist}
  \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
    già.
  \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
    su un filesystem montato readonly.
  \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
    link è piena e non c'è ulteriore spazio disponibile.
  \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
    \texttt{oldname} o di \texttt{newname}.
  \end{errlist}
\end{prototype}

Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare
un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
questa funzione è la:

\begin{prototype}{unistd.h}
{int readlink(const char * path, char * buff, size\_t size)} 
  Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer
  \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
  carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
  piccolo per contenerla.
  
  La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
  -1 per un errore, in caso di errore. La variabile \texttt{errno} viene
  settata secondo i codici di errore:
  \begin{errlist}
  \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
    già.
  \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
    su un filesystem montato readonly.
  \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
    link è piena e non c'è ulteriore spazio disponibile.
  \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
    \texttt{oldname} o di \texttt{newname}.
  \end{errlist}
\end{prototype}