Come visto in sez.~\ref{sec:file_vfs_work} il kernel mette a disposizione
-tramite il \itindex{Virtual~File~System} \textit{Virtual File System} una
-serie di \textit{system call} che consentono di operare sui file in maniera
-generale. Abbiamo trattato quelle relative alla gestione delle proprietà dei
-file nel precedente capitolo, vedremo quelle che si applicano al contenuto dei
-file in questa sezione, iniziando con una breve introduzione sull'architettura
-dei \textit{file descriptor} per poi trattare le funzioni di base e le
-modalità con cui consentono di gestire i dati memorizzati sui file.
+tramite il \textit{Virtual File System} una serie di \textit{system call} che
+consentono di operare sui file in maniera generale. Abbiamo trattato quelle
+relative alla gestione delle proprietà dei file nel precedente capitolo,
+vedremo quelle che si applicano al contenuto dei file in questa sezione,
+iniziando con una breve introduzione sull'architettura dei \textit{file
+ descriptor} per poi trattare le funzioni di base e le modalità con cui
+consentono di gestire i dati memorizzati sui file.
\subsection{I \textit{file descriptor}}
fa aprendo il file con la funzione \func{open} (vedi
sez.~\ref{sec:file_open_close}) che provvederà a localizzare \itindex{inode}
l'\textit{inode} del file e inizializzare i puntatori che rendono disponibili
-le funzioni che il \itindex{Virtual~File~System} VFS mette a disposizione
-(quelle di tab.~\ref{tab:file_file_operations}). Una volta terminate le
-operazioni, il file dovrà essere chiuso, e questo chiuderà il canale di
-comunicazione impedendo ogni ulteriore operazione.
+le funzioni che il VFS mette a disposizione (quelle di
+tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
+file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
+impedendo ogni ulteriore operazione.
All'interno di ogni processo i file aperti sono identificati da un numero
intero non negativo, che viene chiamato \textit{file descriptor}. Quando un
non supportano questa funzione, come ad esempio per i file di
terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
-POSIX però non specifica niente in proposito. Inoltre alcuni
-\index{file!speciali} file speciali, ad esempio \file{/dev/null}, non causano
-un errore ma restituiscono un valore indefinito.
+POSIX però non specifica niente in proposito. Inoltre alcuni file speciali, ad
+esempio \file{/dev/null}, non causano un errore ma restituiscono un valore
+indefinito.
\itindbeg{sparse~file}
\index{file!\textit{hole}|(}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] \param{fd} è un \index{file!speciali} file speciale
- che non supporta la sincronizzazione.
+ \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
+ sincronizzazione.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EIO} e \errval{EROFS} nel loro
significato generico.}
come per le altre funzioni che prendono come argomenti dei
\itindsub{pathname}{relativo} \textit{pathname} relativi, è la possibilità,
quando un \textit{pathname} relativo non fa riferimento ad un file posto
-direttamente nella \index{directory~di~lavoro} directory di lavoro corrente,
-che alcuni dei componenti del \textit{pathname} vengano modificati in
-parallelo alla chiamata a \func{open}, cosa che lascia aperta la possibilità
-di una \itindex{race~condition} \textit{race condition} in cui c'è spazio per
-un \itindex{symlink~attack} \textit{symlink attack} (si ricordi quanto visto
-per \func{access} in sez.~\ref{sec:file_perm_management}).
-
-Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
-corrente è una proprietà del singolo processo; questo significa che quando si
-lavora con i \itindex{thread} \textit{thread} essa sarà la stessa per tutti,
-ma esistono molti casi in cui sarebbe invece utile che ogni singolo
-\itindex{thread} \textit{thread} avesse la sua \index{directory~di~lavoro}
-directory di lavoro.
+direttamente nella directory di lavoro corrente, che alcuni dei componenti del
+\textit{pathname} vengano modificati in parallelo alla chiamata a \func{open},
+cosa che lascia aperta la possibilità di una \itindex{race~condition}
+\textit{race condition} in cui c'è spazio per un \itindex{symlink~attack}
+\textit{symlink attack} (si ricordi quanto visto per \func{access} in
+sez.~\ref{sec:file_perm_management}).
+
+Inoltre come già accennato, la directory di lavoro corrente è una proprietà
+del singolo processo; questo significa che quando si lavora con i
+\textit{thread} essa sarà la stessa per tutti, ma esistono molti casi in cui
+sarebbe invece utile che ogni singolo \textit{thread} avesse la sua directory
+di lavoro.
Per risolvere questi problemi, riprendendo una interfaccia già presente in
Solaris, a fianco delle normali funzioni che operano sui file (come
passare il relativo file descriptor alle varie funzioni che useranno quella
directory come punto di partenza per la risoluzione. In questo modo, anche
quando si lavora con i \itindex{thread} \textit{thread}, si può mantenere una
-\index{directory~di~lavoro} directory di lavoro diversa per ciascuno di essi.
+directory di lavoro diversa per ciascuno di essi.
Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
\textit{race condition}, consente anche di ottenere aumenti di prestazioni
\fhead{fcntl.h}
\fdecl{int openat(int dirfd, const char *pathname, int flags)}
\fdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t mode)}
-\fdesc{Apre un file a partire da una directory di \index{directory~di~lavoro}
- lavoro.}
+\fdesc{Apre un file a partire da una directory di lavoro.}
}
{La funzione ritorna gli stessi valori e gli stessi codici di errore di
da \param{dirfd}. Qualora invece si usi un \itindsub{pathname}{assoluto}
\textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
se per \param{dirfd} si usa il valore speciale \const{AT\_FDCWD}, la
-risoluzione sarà effettuata rispetto alla directory di
-\index{directory~di~lavoro} lavoro corrente del processo. Si tenga presente
-però che questa, come le altre costanti \texttt{AT\_*}, è definita in
-\headfile{fcntl.h}, pertanto se la si vuole usare occorrerà includere comunque
-questo file, anche per le funzioni che non sono definite in esso.
+risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
+processo. Si tenga presente però che questa, come le altre costanti
+\texttt{AT\_*}, è definita in \headfile{fcntl.h}, pertanto se la si vuole
+usare occorrerà includere comunque questo file, anche per le funzioni che non
+sono definite in esso.
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
Come per i file descriptor anche per gli \textit{stream} è possibile spostarsi
all'interno di un file per effettuare operazioni di lettura o scrittura in un
punto prestabilito, sempre che l'operazione di riposizionamento sia supportata
-dal file sottostante lo \textit{stream}, nel caso cioè in cui si ha a che
-fare con quello che viene detto un file ad \textsl{accesso casuale}. Dato che
-in un sistema Unix esistono vari tipi di file, come le fifo ed i
-\index{file!di~dispositivo} file di dispositivo (ad esempio i terminali), non
-è scontato che questo sia vero in generale, pur essendolo sempre nel caso di
-file di dati.
+dal file sottostante lo \textit{stream}, nel caso cioè in cui si ha a che fare
+con quello che viene detto un file ad \textsl{accesso casuale}. Dato che in un
+sistema Unix esistono vari tipi di file, come le fifo ed i file di dispositivo
+(ad esempio i terminali), non è scontato che questo sia vero in generale, pur
+essendolo sempre nel caso di file di dati.
Con Linux ed in generale in ogni sistema unix-like la posizione nel file, come
abbiamo già visto in sez.~\ref{sec:file_lseek}, è espressa da un intero