-\chapter{I file: l'interfaccia standard unix}
+\chapter{I file: l'interfaccia standard Unix}
\label{cha:file_unix_interface}
Esamineremo in questo capitolo la prima delle due interfacce di programmazione
\section{L'architettura di base}
\label{sec:file_base_arch}
-In questa sezione faremo una breve introduzione sulla architettura su cui è
+In questa sezione faremo una breve introduzione sull'architettura su cui è
basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con
differenze nella realizzazione pratica, resta sostanzialmente la stessa in
tutte le implementazione di un sistema unix-like.
campo \var{f\_pos}).
\item un puntatore all'inode\footnote{nel kernel 2.4.x si è in realtà passati
ad un puntatore ad una struttura \var{dentry} che punta a sua volta
- all'inode passando per la nuova struttura del VFS} del file.
+ all'inode passando per la nuova struttura del VFS.} del file.
%\item un puntatore alla tabella delle funzioni \footnote{la struttura
% \var{f\_op} descritta in \secref{sec:file_vfs_work}} che si possono usare
% sul file.
\centering
\includegraphics[width=13cm]{img/procfile}
\caption{Schema della architettura dell'accesso ai file attraverso
- l'interfaccia dei \textit{file descriptor}}
+ l'interfaccia dei \textit{file descriptor}.}
\label{fig:file_proc_file}
\end{figure}
Ritorneremo su questo schema più volte, dato che esso è fondamentale per
\section{Le funzioni base}
\label{sec:file_base_func}
-L'interfaccia standard unix per l'input/output sui file è basata su cinque
+L'interfaccia standard Unix per l'input/output sui file è basata su cinque
funzioni fondamentali: \func{open}, \func{read}, \func{write}, \func{lseek} e
\func{close}, usate rispettivamente per aprire, leggere, scrivere, spostarsi e
chiudere un file.
zero. Se il file è un terminale o una fifo il flag verrà ignorato, negli
altri casi il comportamento non è specificato. \\
\macro{O\_NOFOLLOW} & se \var{pathname} è un link simbolico la chiamata
- fallisce. Questa è una estensione BSD aggiunta in Linux dal kernel 2.1.126.
+ fallisce. Questa è un'estensione BSD aggiunta in Linux dal kernel 2.1.126.
Nelle versioni precedenti i link simbolici sono sempre seguiti, e questa
opzione è ignorata. \\
\macro{O\_DIRECTORY} & se \var{pathname} non è una directory la chiamata
\footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
una \func{read} con un valore nullo e non con un errore, questo introduce
- una ambiguità, dato che come vedremo in \secref{sec:file_read} il ritorno di
+ un'ambiguità, dato che come vedremo in \secref{sec:file_read} il ritorno di
zero da parte di \func{read} ha il significato di una end-of-file.}
Questa caratteristica permette di prevedere qual'è il valore del file
sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
\secref{sec:file_sharing}). Il nuovo file descriptor è settato di default per
restare aperto attraverso una \func{exec} (come accennato in
-\secref{sec:proc_exec}) ed l'offset è settato all'inizio del file.
+\secref{sec:proc_exec}) e l'offset è settato all'inizio del file.
L'argomento \param{mode} specifica i permessi con cui il file viene
eventualmente creato; i valori possibili sono gli stessi già visti in
sommato al riferimento dato da \param{whence}; quest'ultimo può assumere i
seguenti valori\footnote{per compatibilità con alcune vecchie notazioni
questi valori possono essere rimpiazzati rispettivamente con 0, 1 e 2 o con
- \macro{L\_SET}, \macro{L\_INCR} e \macro{L\_XTND}}:
+ \macro{L\_SET}, \macro{L\_INCR} e \macro{L\_XTND}.}:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\macro{SEEK\_SET}] si fa riferimento all'inizio del file: il valore di
\var{offset} è la nuova posizione.
Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
questo caso la funzione ritorna l'errore \macro{EPIPE}. Questo, oltre che per
i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che non
-supportano questa funzione, come ad esempio per le \acr{tty}\footnote{altri
+supportano questa funzione, come ad esempio per le \acr{tty}.\footnote{altri
sistemi, usando \macro{SEEK\_SET}, in questo caso ritornano il numero di
- caratteri che vi sono stati scritti}. Lo standard POSIX però non specifica
+ caratteri che vi sono stati scritti.} Lo standard POSIX però non specifica
niente al proposito. Infine alcuni device, ad esempio \file{/dev/null}, non
causano un errore ma restituiscono un valore indefinito.
\macro{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è
bloccata in attesa di dati in ingresso e viene interrotta da un segnale; in
tal caso l'azione da prendere è quella di rieseguire la funzione. Torneremo
-sull'argomento in \secref{sec:signal_xxx}.
+sull'argomento in \secref{sec:sig_gen_beha}.
La seconda si verifica quando il file è in modalità non bloccante e non ci
sono dati in ingresso: la funzione allora ritorna immediatamente con un errore
Specification}\footnote{questa funzione, e l'analoga \func{pwrite} sono
state aggiunte nel kernel 2.1.60, il supporto nelle \acr{glibc}, compresa
l'emulazione per i vecchi kernel che non hanno la system call, è stato
- aggiunto con la versione 2.1} (quello che viene chiamato normalmente Unix98,
+ aggiunto con la versione 2.1.} (quello che viene chiamato normalmente Unix98,
vedi \secref{sec:intro_opengroup}) è stata introdotta la definizione di
un'altra funzione di lettura, \func{pread}, che diventa accessibile con la
definizione:
da \var{count}, a meno di un errore. Negli altri casi si ha lo stesso
comportamento di \func{read}.
-Anche per \func{write} lo standard Unix98 definisce una analoga \func{pwrite}
+Anche per \func{write} lo standard Unix98 definisce un'analoga \func{pwrite}
per scrivere alla posizione indicata senza modificare la posizione corrente
nel file, il suo prototipo è:
\begin{prototype}{unistd.h}
Si noti inoltre che anche i flag di stato del file (quelli settati
dall'argomento \param{flag} di \func{open}) essendo tenuti nella voce della
\textit{file table}\footnote{per la precisione nel campo \var{f\_flags} di
- \var{file}}, vengono in questo caso condivisi. Ai file però sono associati
+ \var{file}.}, vengono in questo caso condivisi. Ai file però sono associati
anche altri flag, dei quali l'unico usato al momento è \macro{FD\_CLOEXEC},
detti \textit{file descriptor flags}. Questi ultimi sono tenuti invece in
\var{file\_struct}, e perciò sono specifici di ciascun processo e non vengono
corrente settata con la \func{lseek} che non corrisponde più alla fine del
file, e la successiva \func{write} sovrascriverà i dati del secondo processo.
-Il problema è che usare due system call in successione non è una operazione
+Il problema è che usare due system call in successione non è un'operazione
atomica; il problema è stato risolto introducendo la modalità
\macro{O\_APPEND}. In questo caso infatti, come abbiamo descritto in
precedenza, è il kernel che aggiorna automaticamente la posizione alla fine
del file prima di effettuare la scrittura, e poi estende il file. Tutto questo
avviene all'interno di una singola system call (la \func{write}) che non
-essendo interrompibile da un altro processo costituisce una operazione
-atomica.
+essendo interrompibile da un altro processo costituisce un'operazione atomica.
Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
creare un file di lock, bloccandosi se il file esiste. In questo caso la
Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
sistema mette a disposizione delle funzioni che provvedono a forzare lo
-scarico dei dati dai buffer del kernel\footnote{come già accennato neanche
+scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
questo da la garanzia assoluta che i dati siano integri dopo la chiamata,
l'hardware dei dischi è in genere dotato di un suo meccanismo interno che
- può ritardare ulteriormente la scrittura effettiva.}. La prima di queste
+ può ritardare ulteriormente la scrittura effettiva.} La prima di queste
funzioni è \func{sync} il cui prototipo è:
\begin{prototype}{unistd.h}{int sync(void)}
Si tenga presente che questo non comporta la sincronizzazione della
directory che contiene il file (e scrittura della relativa voce su
-disco) che deve essere effettuata esplicitamente\footnote{in realtà per
+disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
il kernel provvede anche alla sincronizzazione automatica delle voci
- delle directory.}.
+ delle directory.}
\subsection{La funzioni \func{dup} e \func{dup2}}
Per determinare le modalità di accesso inoltre è necessario estrarre i bit di
accesso (ottenuti con il comando \macro{F\_GETFL}); infatti la definizione
corrente non assegna bit separati a \macro{O\_RDONLY}, \macro{O\_WRONLY} e
-\macro{O\_RDWR}\footnote{posti rispettivamente ai valori 0, 1 e 2}, per cui il
+\macro{O\_RDWR},\footnote{posti rispettivamente ai valori 0, 1 e 2.} per cui il
valore si ottiene eseguendo un AND binario del valore di ritorno di
\func{fcntl} con la maschera \macro{O\_ACCMODE} anch'essa definita in
\file{fcntl.h}.