%% fileunix.tex
%%
-%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
-%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
%% license is included in the section entitled "GNU Free Documentation
%% License".
dalle system call, che non prevede funzionalità evolute come la
bufferizzazione o funzioni di lettura o scrittura formattata, e sulla quale è
costruita anche l'interfaccia definita dallo standard ANSI C che affronteremo
-al \capref{cha:files_std_interface}.
+al cap.~\ref{cha:files_std_interface}.
\subsection{L'architettura dei \textit{file descriptor}}
\label{sec:file_fd}
-\index{file!descriptor|(} Per poter accedere al contenuto di un file occorre
+\index{file!descriptor|(}
+
+Per poter accedere al contenuto di un file occorre
creare un canale di comunicazione con il kernel che renda possibile operare su
-di esso (si ricordi quanto visto in \secref{sec:file_vfs_work}). Questo si fa
-aprendo il file con la funzione \func{open} che provvederà a localizzare
+di esso (si ricordi quanto visto in sez.~\ref{sec:file_vfs_work}). Questo si
+fa aprendo il file con la funzione \func{open} che provvederà a localizzare
l'inode\index{inode} del file e inizializzare i puntatori che rendono
disponibili le funzioni che il VFS mette a disposizione (riportate in
-\tabref{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.
+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 intero non
negativo, chiamato appunto \textit{file descriptor}.
sua volta all'inode\index{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
+% \var{f\_op} descritta in sez.~\ref{sec:file_vfs_work}} che si possono usare
% sul file.
\end{itemize*}
-In \figref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
+In fig.~\ref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
questa architettura, ed in cui si sono evidenziate le interrelazioni fra le
varie strutture di dati sulla quale essa è basata.
+Ritorneremo su questo schema più volte, dato che esso è fondamentale per
+capire i dettagli del funzionamento dell'interfaccia dei \textit{file
+ descriptor}.
+\index{file!descriptor|)}
+
\begin{figure}[htb]
\centering
\includegraphics[width=13cm]{img/procfile}
l'interfaccia dei \textit{file descriptor}.}
\label{fig:file_proc_file}
\end{figure}
-Ritorneremo su questo schema più volte, dato che esso è fondamentale per
-capire i dettagli del funzionamento dell'interfaccia dei \textit{file
- descriptor}.
-\index{file!descriptor|)}
-
stato chiuso nessuno in precedenza).
In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
-processo viene lanciato con almeno tre file aperti. Questi, per quanto appena
-detto, avranno come \textit{file descriptor}\index{file!descriptor} i valori
-0, 1 e 2. Benché questa sia soltanto una convenzione, essa è seguita dalla
-gran parte delle applicazioni, e non aderirvi potrebbe portare a gravi
-problemi di interoperabilità.
-
-Il primo file è sempre associato a quello che viene chiamato \textit{standard
- input}. È cioè il file da cui il processo si aspetta di ricevere i dati in
-ingresso (nel caso della shell, è associato all'ingresso dal terminale, e
-quindi alla lettura della tastiera). Il secondo file è il cosiddetto
-\textit{standard output}, cioè il file su cui ci si aspetta debbano essere
-inviati i dati in uscita (sempre nel caso della shell, è associato all'uscita
-del terminale, e quindi alla scrittura sullo schermo). Il terzo è lo
-\textit{standard error}, su cui viene inviato l'output relativo agli errori,
-ed è anch'esso associato all'uscita del terminale. Lo standard POSIX.1
-provvede tre costanti simboliche, definite nell'header \file{unistd.h}, al
-posto di questi valori numerici:
+processo viene lanciato dalla shell con almeno tre file aperti. Questi, per
+quanto appena detto, avranno come \textit{file
+ descriptor}\index{file!descriptor} i valori 0, 1 e 2. Benché questa sia
+soltanto una convenzione, essa è seguita dalla gran parte delle applicazioni,
+e non aderirvi potrebbe portare a gravi problemi di interoperabilità.
+
+Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
+il file da cui il processo si aspetta di ricevere i dati in ingresso. Il
+secondo file è il cosiddetto \textit{standard output}, cioè quello su cui ci
+si aspetta debbano essere inviati i dati in uscita. Il terzo è lo
+\textit{standard error}, su cui viene inviata l'uscita relativa agli errori.
+Nel caso della shell tutti questi file sono associati al terminale di
+controllo, e corrispondono quindi alla lettura della tastiera per l'ingresso e
+alla scrittura sul terminale per l'uscita. Lo standard POSIX.1 provvede, al
+posto dei valori numerici, tre costanti simboliche, definite in
+tab.~\ref{tab:file_std_files}.
+
\begin{table}[htb]
\centering
\footnotesize
\label{tab:file_std_files}
\end{table}
-In \figref{tab:file_std_files} si è utilizzata questa situazione come esempio,
+In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa,
facendo riferimento ad un programma in cui lo \textit{standard input} è
associato ad un file mentre lo \textit{standard output} e lo \textit{standard
error} sono entrambi associati ad un altro file (e quindi utilizzano lo
descriptor dentro \struct{file\_struct}; questo limite intrinseco nei kernel
più recenti non sussiste più, dato che si è passati da un vettore ad una
lista, ma restano i limiti imposti dall'amministratore (vedi
-\secref{sec:sys_limits}).
+sez.~\ref{sec:sys_limits}).
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.
-
-La gran parte delle operazioni sui file si effettua attraverso queste cinque
-funzioni, esse vengono chiamate anche funzioni di I/O non bufferizzato dato
-che effettuano le operazioni di lettura e scrittura usando direttamente le
-system call del kernel.
+chiudere un file. La gran parte delle operazioni sui file si effettua
+attraverso queste cinque funzioni, esse vengono chiamate anche funzioni di I/O
+non bufferizzato dato che effettuano le operazioni di lettura e scrittura
+usando direttamente le system call del kernel.
\subsection{La funzione \func{open}}
\label{sec:file_open}
La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è
-quella che crea l'associazione fra un pathname ed un file descriptor, il suo
-prototipo è:
+quella che crea l'associazione fra un \itindex{pathname}\textit{pathname} ed
+un file descriptor, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
dispositivo che non esiste.
\item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
di un programma in esecuzione.
- \item[\errcode{ELOOP}] si sono incontrati troppi link simbolici nel risolvere
- pathname o si è indicato \const{O\_NOFOLLOW} e \param{pathname} è un link
- simbolico.
+ \item[\errcode{ELOOP}] si sono incontrati troppi link simbolici nel
+ risolvere il \textit{pathname} o si è indicato \const{O\_NOFOLLOW} e
+ \param{pathname} è un link simbolico.
\end{errlist}
ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{EROFS}, \errval{EFAULT}, \errval{ENOSPC}, \errval{ENOMEM},
\end{functions}
La funzione apre il file, usando il primo file descriptor libero, e crea
-l'opportuna voce (cioè la struttura \struct{file}) nella file table. Viene
-usato sempre il file descriptor con il valore più basso.
+l'opportuna voce (cioè la struttura \struct{file}) nella \textit{file table}.
+Viene sempre restituito come valore di ritorno il file descriptor con il
+valore più basso disponibile.
\begin{table}[!htb]
\centering
\textbf{Flag} & \textbf{Descrizione} \\
\hline
\hline % modalità di accesso al file
- \const{O\_RDONLY} & apre il file in sola lettura. \\
- \const{O\_WRONLY} & apre il file in sola scrittura. \\
- \const{O\_RDWR} & apre il file in lettura/scrittura. \\
+ \const{O\_RDONLY} & apre il file in sola lettura, le \acr{glibc}
+ definiscono anche \const{O\_READ} come sinonimo. \\
+ \const{O\_WRONLY} & apre il file in sola scrittura, le \acr{glibc}
+ definiscono anche \const{O\_WRITE} come sinonimo. \\
+ \const{O\_RDWR} & apre il file sia in lettura che in scrittura. \\
\hline % modalità di apertura del file
\hline
\const{O\_CREAT} & se il file non esiste verrà creato, con le regole di
- titolarità del file viste in \secref{sec:file_ownership}. L'argomento
- \param{mode} deve essere specificato. \\
- \const{O\_EXCL} & usato in congiunzione con \const{O\_CREAT} fa sì che
- l'esistenza del file diventi un errore\protect\footnotemark\ che fa fallire
- \func{open} con \errcode{EEXIST}. \\
- \const{O\_NONBLOCK} & apre il file in modalità non bloccante. Questo
- valore specifica anche una modalità di operazione (vedi sotto), e
- comporta che \func{open} ritorni immediatamente (l'opzione ha senso
- solo per le fifo, torneremo questo in \secref{sec:ipc_named_pipe}). \\
- \const{O\_NOCTTY} & se \param{pathname} si riferisce ad un dispositivo di
- terminale, questo non diventerà il terminale di controllo, anche se il
- processo non ne ha ancora uno (si veda \secref{sec:sess_ctrl_term}). \\
+ titolarità del file viste in
+ sez.~\ref{sec:file_ownership}. Con questa opzione
+ l'argomento \param{mode} deve essere specificato. \\
+ \const{O\_EXCL} & usato in congiunzione con \const{O\_CREAT} fa sì che
+ la precedente esistenza del file diventi un
+ errore\protect\footnotemark\ che fa fallire
+ \func{open} con \errcode{EEXIST}. \\
+ \const{O\_NONBLOCK}& apre il file in modalità non bloccante. Questo
+ valore specifica anche una modalità di operazione (vedi
+ sotto), e comporta che \func{open} ritorni
+ immediatamente (l'opzione ha senso solo per le fifo,
+ torneremo questo in sez.~\ref{sec:ipc_named_pipe}). \\
+ \const{O\_NOCTTY}& se \param{pathname} si riferisce ad un dispositivo di
+ terminale, questo non diventerà il terminale di
+ controllo, anche se il processo non ne ha ancora uno
+ (si veda sez.~\ref{sec:sess_ctrl_term}). \\
\const{O\_SHLOCK} & opzione di BSD, acquisisce uno shared lock (vedi
- \secref{sec:file_locking}) sul file. Non è disponibile in Linux. \\
+ sez.~\ref{sec:file_locking}) sul file. Non è
+ disponibile in Linux. \\
\const{O\_EXLOCK} & opzione di BSD, acquisisce uno lock esclusivo (vedi
- \secref{sec:file_locking}) sul file. Non è disponibile in Linux. \\
- \const{O\_TRUNC} & se il file esiste ed è un file di dati e la modalità di
- apertura consente la scrittura, allora la sua lunghezza verrà troncata a
- zero. Se il file è un terminale o una fifo il flag verrà ignorato, negli
- altri casi il comportamento non è specificato. \\
- \const{O\_NOFOLLOW} & se \param{pathname} è un link simbolico la chiamata
- 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. \\
- \const{O\_DIRECTORY} & se \param{pathname} non è una directory la chiamata
- fallisce. Questo flag è specifico di Linux ed è stato introdotto con il
- kernel 2.1.126 per evitare dei
- \textit{DoS}\index{DoS}\protect\footnotemark\ quando
- \func{opendir} viene chiamata su una
- fifo o su un device di unità a nastri, non deve essere utilizzato al di
- fuori dell'implementazione di \func{opendir}. \\
- \const{O\_LARGEFILE} & nel caso di sistemi a 32 bit che supportano file di
- grandi dimensioni consente di aprire file le cui dimensioni non possono
- essere rappresentate da numeri a 31 bit. \\
+ sez.~\ref{sec:file_locking}) sul file. Non è
+ disponibile in Linux. \\
+ \const{O\_TRUNC} & se il file esiste ed è un file di dati e la modalità di
+ apertura consente la scrittura, allora la sua
+ lunghezza verrà troncata a zero. Se il file è un
+ terminale o una fifo il flag verrà ignorato, negli
+ altri casi il comportamento non è specificato. \\
+ \const{O\_NOFOLLOW}&se \param{pathname} è un link simbolico la chiamata
+ 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. \\
+ \const{O\_DIRECTORY}& se \param{pathname} non è una directory la chiamata
+ fallisce. Questo flag è specifico di Linux ed è stato
+ introdotto con il kernel 2.1.126 per evitare dei
+ \textit{DoS}\index{DoS}\protect\footnotemark\ quando
+ \func{opendir} viene chiamata su una fifo o su un
+ device di unità a nastri, non deve essere utilizzato
+ al di fuori dell'implementazione di \func{opendir}. \\
+ \const{O\_LARGEFILE}& nel caso di sistemi a 32 bit che supportano file di
+ grandi dimensioni consente di aprire file le cui
+ dimensioni non possono essere rappresentate da numeri
+ a 31 bit. \\
\hline
\hline % modalità di operazione col file
\const{O\_APPEND} & il file viene aperto in append mode. Prima di ciascuna
- scrittura la posizione corrente viene sempre impostata alla fine del
- file. Può causare corruzione del file con NFS se più di un processo scrive
- allo stesso tempo.\footnotemark\\
- \const{O\_NONBLOCK} & il file viene aperto in modalità non bloccante per
- le operazioni di I/O (che tratteremo in \secref{sec:file_noblocking}):
- questo significa il fallimento di \func{read} in assenza di dati da
- leggere e quello di \func{write} in caso di impossibilità di scrivere
- immediatamente. Questa modalità ha senso solo per le fifo e per alcuni
- file di dispositivo. \\
+ scrittura la posizione corrente viene sempre impostata
+ alla fine del file. Con NFS si può avere una
+ corruzione del file se più di un processo scrive allo
+ stesso tempo.\footnotemark\\
+ \const{O\_NONBLOCK}&il file viene aperto in modalità non bloccante per
+ le operazioni di I/O (che tratteremo in
+ sez.~\ref{sec:file_noblocking}): questo significa il
+ fallimento di \func{read} in assenza di dati da
+ leggere e quello di \func{write} in caso di
+ impossibilità di scrivere immediatamente. Questa
+ modalità ha senso solo per le fifo e per alcuni file
+ di dispositivo. \\
\const{O\_NDELAY} & in Linux\footnotemark\ è sinonimo di
- \const{O\_NONBLOCK}.\\
- \const{O\_ASYNC} & apre il file per l'I/O in modalità
- asincrona (vedi \secref{sec:file_asyncronous_io}). Quando è impostato viene
- generato il segnale \const{SIGIO} tutte le volte che sono disponibili
- dati in input sul file. \\
- \const{O\_SYNC} & apre il file per l'input/output sincrono, ogni
- \func{write} bloccherà fino al completamento della scrittura di tutti dati
- sul sull'hardware sottostante.\\
- \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}. \\
- \const{O\_NOATIME} & blocca l'aggiornamento dei tempi di accesso dei
- file (vedi \secref{sec:file_file_times}). In Linux questa opzione non è
- disponibile per il singolo file ma come opzione per il filesystem in fase
- di montaggio.\\
+ \const{O\_NONBLOCK}.\\
+ \const{O\_ASYNC} & apre il file per l'I/O in modalità asincrona (vedi
+ sez.~\ref{sec:file_asyncronous_io}). Quando è
+ impostato viene generato il segnale \const{SIGIO}
+ tutte le volte che sono disponibili dati in input
+ sul file. \\
+ \const{O\_SYNC} & apre il file per l'input/output sincrono: ogni
+ \func{write} bloccherà fino al completamento della
+ scrittura di tutti i dati sull'hardware sottostante.\\
+ \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}, usato da BSD. \\
+ \const{O\_DSYNC} & richiede una variante di I/O sincorno definita nello
+ standard POSIX; definita a partire dal kernel 2.1.130
+ come sinonimo di \const{O\_SYNC}. \\
+ \const{O\_RSYNC} & richiede una variante di I/O sincorno definita nello
+ standard POSIX; definita a partire dal kernel 2.1.130
+ come sinonimo di \const{O\_SYNC}. \\
+ \const{O\_NOATIME}& blocca l'aggiornamento dei tempi di accesso dei
+ file (vedi sez.~\ref{sec:file_file_times}). Per molti
+ filesystem questa funzionalità non è disponibile per
+ il singolo file ma come opzione generale da
+ specificare in fase di montaggio.\\
+ \const{O\_DIRECT} & esegue l'I/O direttamente dai buffer in user space, ed
+ in maniera sincrona, in modo da scavalcare i
+ meccanismi di caching del kernel. In gebere questo
+ peggiora le prestazioni tranne per casi speciali in
+ cui sono le applicazioni\footnotemark a gestire il
+ caching. Per i kernel della serie 2.4 si deve
+ garantire che i buffer in user space siano allineati
+ alle dimensioni dei blocchi del filesystem; per il
+ kernel 2.6 basta che siano allineati a multipli di 512
+ byte.\\
\hline
\end{tabular}
\caption{Valori e significato dei vari bit del \textit{file status flag}.}
\footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
- \textsl{file di lock}\index{file!di lock} possono incorrere in una race
- condition\index{race condition}. Si consiglia come alternativa di usare un
- file con un nome univoco e la funzione \func{link} per verificarne
- l'esistenza (vedi \secref{sec:ipc_file_lock}).}
+ \textsl{file di lock}\index{file!di lock} possono incorrere in una
+ \textit{race condition}\itindex{race~condition}. Si consiglia come
+ alternativa di usare un file con un nome univoco e la funzione \func{link}
+ per verificarne l'esistenza (vedi sez.~\ref{sec:ipc_file_lock}).}
\footnotetext[3]{\textit{Denial of Service}\index{DoS}, si chiamano così
attacchi miranti ad impedire un servizio causando una qualche forma di
\footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
il kernel deve simularla, ma questo comporta la possibilità di una race
- condition, vedi \secref{sec:file_atomic}.}
+ condition, vedi sez.~\ref{sec:file_atomic}.}
\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
- un'ambiguità, dato che come vedremo in \secref{sec:file_read} il ritorno di
+ un'ambiguità, dato che come vedremo in sez.~\ref{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
+\footnotetext[6]{l'opzione è stata introdotta dalla SGI in IRIX, e serve
+ sostanzialmente a permettere ad alcuni programmi (in genere database) la
+ gestione diretta della bufferizzazione dell'I/O in quanto essi sono in grado
+ di ottimizzarla al meglio per le loro prestazioni; l'opzione è presente
+ anche in FreeBSD, senza limiti di allineamento dei buffer. In Linux è stata
+ introdotta con il kernel 2.4.10, le versioni precedenti la ignorano.}
+
+
+Questa caratteristica permette di prevedere qual è il valore del file
descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
alcune applicazioni per sostituire i file corrispondenti ai file standard
-visti in \secref{sec:file_std_descr}: se ad esempio si chiude lo standard
+visti in sez.~\ref{sec:file_std_descr}: se ad esempio si chiude lo standard
input e si apre subito dopo un nuovo file questo diventerà il nuovo standard
-input (avrà cioè il file descriptor 0). Il nuovo file descriptor non è
-condiviso con nessun altro processo (torneremo sulla condivisione dei file, in
-genere accessibile dopo una \func{fork}, in \secref{sec:file_sharing}) ed è
-impostato per restare aperto attraverso una \func{exec} (come accennato in
-\secref{sec:proc_exec}); l'offset è impostato all'inizio del file.
+input (avrà cioè il file descriptor 0).
+
+Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo
+sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
+sez.~\ref{sec:file_sharing}) ed è impostato per restare aperto attraverso una
+\func{exec} (come accennato in sez.~\ref{sec:proc_exec}); l'offset è impostato
+all'inizio del file.
L'argomento \param{mode} indica i permessi con cui il file viene creato; i
-valori possibili sono gli stessi già visti in \secref{sec:file_perm_overview}
+valori possibili sono gli stessi già visti in sez.~\ref{sec:file_perm_overview}
e possono essere specificati come OR binario delle costanti descritte in
-\tabref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di
-\var{umask} (vedi \secref{sec:file_umask}) per il processo.
+tab.~\ref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di
+\var{umask} (vedi sez.~\ref{sec:file_umask}) per il processo.
La funzione prevede diverse opzioni, che vengono specificate usando vari bit
dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire
il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
campo \var{f\_flags} della struttura \struct{file} (al solito si veda lo schema
-di \figref{fig:file_proc_file}). Essi sono divisi in tre categorie
+di fig.~\ref{fig:file_proc_file}). Essi sono divisi in tre categorie
principali:
\begin{itemize*}
\item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
che controllano) con una \func{fcntl}.
\end{itemize*}
-In \tabref{tab:file_open_flags} sono riportate, ordinate e divise fra loro
+In tab.~\ref{tab:file_open_flags} sono riportate, ordinate e divise fra loro
secondo le tre modalità appena elencate, le costanti mnemoniche associate a
ciascuno di questi bit. Dette costanti possono essere combinate fra loro con
un OR aritmetico per costruire il valore (in forma di maschera binaria)
\end{prototype}
La chiusura di un file rilascia ogni blocco (il \textit{file
- locking}\index{file!locking} è trattato in \secref{sec:file_locking}) che il
-processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
+ locking}\index{file!locking} è trattato in sez.~\ref{sec:file_locking}) che
+il processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
riferimento (di eventuali copie) ad un file aperto, tutte le risorse nella
file table vengono rilasciate. Infine se il file descriptor era l'ultimo
riferimento ad un file su disco quest'ultimo viene cancellato.
In ogni caso una \func{close} andata a buon fine non garantisce che i dati
siano stati effettivamente scritti su disco, perché il kernel può decidere di
ottimizzare l'accesso a disco ritardandone la scrittura. L'uso della funzione
-\func{sync} (vedi \secref{sec:file_sync}) effettua esplicitamente il
+\func{sync} (vedi sez.~\ref{sec:file_sync}) effettua esplicitamente il
\emph{flush} dei dati, ma anche in questo caso resta l'incertezza dovuta al
comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
dell'accesso al disco che ritardano la scrittura dei dati, da cui l'abitudine
\subsection{La funzione \func{lseek}}
\label{sec:file_lseek}
-Come già accennato in \secref{sec:file_fd} a ciascun file aperto è associata
+Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
una \textsl{posizione corrente nel file} (il cosiddetto \textit{file offset},
mantenuto nel campo \var{f\_pos} di \struct{file}) espressa da un numero intero
positivo come numero di byte dall'inizio del file. Tutte le operazioni di
per ottenere la nuova posizione corrente.
\end{basedescript}
-Come accennato in \secref{sec:file_file_size} con \func{lseek} è possibile
+Come accennato in sez.~\ref{sec:file_file_size} con \func{lseek} è possibile
impostare la posizione corrente anche oltre la fine del file, e alla
successiva scrittura il file sarà esteso. La chiamata non causa nessun accesso
al file, si limita a modificare la posizione corrente (cioè il valore
-\var{f\_pos} in \param{file}, vedi \figref{fig:file_proc_file}). Dato che la
+\var{f\_pos} in \param{file}, vedi fig.~\ref{fig:file_proc_file}). Dato che la
funzione ritorna la nuova posizione, usando il valore zero per \param{offset}
si può riottenere la posizione corrente nel file chiamando la funzione con
\code{lseek(fd, 0, SEEK\_CUR)}.
la successiva scrittura avvenga alla fine del file, infatti se questo è stato
aperto anche da un altro processo che vi ha scritto, la fine del file può
essersi spostata, ma noi scriveremo alla posizione impostata in precedenza
-(questa è una potenziale sorgente di
-\textit{race condition}\index{race condition}, vedi \secref{sec:file_atomic}).
+(questa è una potenziale sorgente di \itindex{race~condition}\textit{race
+ condition}, vedi sez.~\ref{sec:file_atomic}).
Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
questo caso la funzione ritorna l'errore \errcode{EPIPE}. Questo, oltre che per
quando si legge da un terminale, da una fifo o da una pipe. In tal caso
infatti, se non ci sono dati in ingresso, la \func{read} si blocca (a meno di
non aver selezionato la modalità non bloccante, vedi
-\secref{sec:file_noblocking}) e ritorna solo quando ne arrivano; se il numero
+sez.~\ref{sec:file_noblocking}) e ritorna solo quando ne arrivano; se il numero
di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma
con un numero di byte inferiore a quelli richiesti.
Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un
-socket\index{socket}, come vedremo in \secref{sec:sock_io_behav}), o per la
+socket\index{socket}, come vedremo in sez.~\ref{sec:sock_io_behav}), o per la
lettura da certi file di dispositivo, come le unità a nastro, che
-restituiscono sempre i dati ad un singolo blocco alla volta.
-
-In realtà anche le due condizioni segnalate dagli errori \errcode{EINTR} e
-\errcode{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 intraprendere è quella di rieseguire la funzione.
-Torneremo in dettaglio sull'argomento in \secref{sec:sig_gen_beha}. La
-seconda si verifica quando il file è in modalità non bloccante (vedi
-\secref{sec:file_noblocking}) e non ci sono dati in ingresso: la funzione
-allora ritorna immediatamente con un errore \errcode{EAGAIN}\footnote{BSD usa
- per questo errore la costante \errcode{EWOULDBLOCK}, in Linux, con le
- \acr{glibc}, questa è sinonima di \errcode{EAGAIN}.} che indica soltanto che
-occorrerà provare a ripetere la lettura.
+restituiscono sempre i dati ad un singolo blocco alla volta, o come le linee
+seriali, che restituiscono solo i dati ricevuti fino al momento della lettura.
+
+Infine anche le due condizioni segnalate dagli errori \errcode{EINTR} ed
+\errcode{EAGAIN} non sono propriamente degli 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 intraprendere è quella di
+rieseguire la funzione. Torneremo in dettaglio sull'argomento in
+sez.~\ref{sec:sig_gen_beha}. La seconda si verifica quando il file è aperto
+in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
+dati in ingresso: la funzione allora ritorna immediatamente con un errore
+\errcode{EAGAIN}\footnote{BSD usa per questo errore la costante
+ \errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
+ \errcode{EAGAIN}.} che indica soltanto che non essendoci al momento dati
+disponibili occorre provare a ripetere la lettura in un secondo tempo.
La funzione \func{read} è una delle system call fondamentali, esistenti fin
dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix
l'emulazione per i vecchi kernel che non hanno la system call, è stato
aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
delle librerie la funzione non è disponibile.} (quello che viene chiamato
-normalmente Unix98, vedi \secref{sec:intro_opengroup}) è stata introdotta la
+normalmente Unix98, vedi sez.~\ref{sec:intro_opengroup}) è stata introdotta la
definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
\begin{prototype}{unistd.h}
{ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
in caso di errore, nel qual caso \var{errno} assumerà i valori già visti per
\func{read} e \func{lseek}.}
\end{prototype}
-\noindent che però diventa accessibile solo con la definizione della macro:
+
+La funzione prende esattamente gli stessi argomenti di \func{read} con lo
+stesso significato, a cui si aggiunge l'argomento \func{offset} che indica una
+posizione sul file. Indetico è il comportamento ed il valore di ritorno. La
+funzione serve quando si vogliono leggere dati dal file senza modificare la
+posizione corrente.
+
+L'uso di \func{pread} è equivalente all'esecuzione di una \func{read} seguita
+da una \func{lseek} che riporti al valore precedente la posizione corrente sul
+file, ma permette di eseguire l'operazione atomicamente. Questo può essere
+importante quando la posizione sul file viene condivisa da processi diversi
+(vedi sez.~\ref{sec:file_sharing}). Il valore di
+\param{offset} fa sempre riferimento all'inizio del file.
+
+La funzione \func{pread} è disponibile anche in Linux, però diventa
+accessibile solo attivando il supporto delle estensioni previste dalle
+\textit{Single Unix Specification} con la definizione della macro:
\begin{verbatim}
#define _XOPEN_SOURCE 500
\end{verbatim}
+e si ricordi di definire questa macro prima dell'inclusione del file di
+dichiarazioni \file{unistd.h}.
-Questa funzione serve quando si vogliono leggere dati dal file senza
-modificare la posizione corrente. È equivalente all'esecuzione di una
-\func{read} seguita da una \func{lseek} che riporti al valore precedente la
-posizione corrente sul file, ma permette di eseguire l'operazione
-atomicamente. Questo può essere importante quando la posizione sul file viene
-condivisa da processi diversi (vedi \secref{sec:file_sharing}). Il valore di
-\param{offset} fa sempre riferimento all'inizio del file.
\subsection{La funzione \func{write}}
\label{sec:file_write}
-Una volta che un file è stato aperto (con il permesso in scrittura) su può
+Una volta che un file è stato aperto (con il permesso in scrittura) si può
scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
\begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
della gestione file in un sistema unix-like, esaminando in dettaglio il
comportamento delle funzioni base, inoltre tratteremo le funzioni che
permettono di eseguire alcune operazioni avanzate con i file (il grosso
-dell'argomento sarà comunque affrontato in \capref{cha:file_advanced}).
+dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
\subsection{La condivisione dei files}
\label{sec:file_sharing}
-In \secref{sec:file_fd} abbiamo descritto brevemente l'architettura
+In sez.~\ref{sec:file_fd} abbiamo descritto brevemente l'architettura
dell'interfaccia con i file da parte di un processo, mostrando in
-\figref{fig:file_proc_file} le principali strutture usate dal kernel;
+fig.~\ref{fig:file_proc_file} le principali strutture usate dal kernel;
esamineremo ora in dettaglio le conseguenze che questa architettura ha nei
confronti dell'accesso allo stesso file da parte di processi diversi.
\end{figure}
Il primo caso è quello in cui due processi diversi aprono lo stesso file
-su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una
-situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun
+su disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
+situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
processo avrà una sua voce nella \textit{file table} referenziata da un
diverso file descriptor nella sua \struct{file\_struct}. Entrambe le voci
nella \textit{file table} faranno però riferimento allo stesso
Il secondo caso è quello in cui due file descriptor di due processi diversi
puntino alla stessa voce nella \textit{file table}; questo è ad esempio il
caso dei file aperti che vengono ereditati dal processo figlio all'esecuzione
-di una \func{fork} (si ricordi quanto detto in \secref{sec:proc_fork}). La
-situazione è illustrata in \figref{fig:file_acc_child}; dato che il processo
+di una \func{fork} (si ricordi quanto detto in sez.~\ref{sec:proc_fork}). La
+situazione è illustrata in fig.~\ref{fig:file_acc_child}; dato che il processo
figlio riceve una copia dello spazio di indirizzi del padre, riceverà anche
una copia di \struct{file\_struct} e relativa tabella dei file aperti.
In questo modo padre e figlio avranno gli stessi file descriptor che faranno
riferimento alla stessa voce nella \textit{file table}, condividendo così la
posizione corrente sul file. Questo ha le conseguenze descritte a suo tempo in
-\secref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
+sez.~\ref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
corrente nel file varierà per entrambi i processi (in quanto verrà modificato
\var{f\_pos} che è lo stesso per entrambi).
maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
utilizzare meccanismi di sincronizzazione più complessi (come il \textit{file
- locking}\index{file!locking}, che esamineremo in \secref{sec:file_locking}).
+ locking}\index{file!locking}, che esamineremo in
+sez.~\ref{sec:file_locking}).
Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
vari processi devono scrivere alla fine di un file (ad esempio un file di
-log). Come accennato in \secref{sec:file_lseek} impostare la posizione alla
-fine del file e poi scrivere può condurre ad una \textit{race
- condition}\index{race condition}: infatti può succedere che un secondo
-processo scriva alla fine del file fra la \func{lseek} e la \func{write}; in
-questo caso, come abbiamo appena visto, il file sarà esteso, ma il nostro
-primo processo avrà ancora la posizione corrente impostata con la \func{lseek}
-che non corrisponde più alla fine del file, e la successiva \func{write}
-sovrascriverà i dati del secondo processo.
+log). Come accennato in sez.~\ref{sec:file_lseek} impostare la posizione alla
+fine del file e poi scrivere può condurre ad una
+\itindex{race~condition}\textit{race condition}: infatti può succedere che un
+secondo processo scriva alla fine del file fra la \func{lseek} e la
+\func{write}; in questo caso, come abbiamo appena visto, il file sarà esteso,
+ma il nostro primo processo avrà ancora la posizione corrente impostata 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 è un'operazione
atomica; il problema è stato risolto introducendo la modalità
creare un \textsl{file di lock}\index{file!di lock}, bloccandosi se il file
esiste. In questo caso la sequenza logica porterebbe a verificare prima
l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
-di nuovo avremmo la possibilità di una race condition\index{race condition} da
-parte di un altro processo che crea lo stesso file fra il controllo e la
-creazione.
+di nuovo avremmo la possibilità di una \textit{race
+ condition}\itindex{race~condition} da parte di un altro processo che crea lo
+stesso file fra il controllo e la creazione.
Per questo motivo sono stati introdotti per \func{open} i due flag
\const{O\_CREAT} e \const{O\_EXCL}. In questo modo l'operazione di controllo
dell'esistenza del file (con relativa uscita dalla funzione con un errore) e
creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno
di una singola system call (per i dettagli sull'uso di questa caratteristica
-si veda \secref{sec:ipc_file_lock}).
+si veda sez.~\ref{sec:ipc_file_lock}).
\subsection{La funzioni \func{sync} e \func{fsync}}
\label{sec:file_sync}
-Come accennato in \secref{sec:file_close} tutte le operazioni di scrittura
+Come accennato in sez.~\ref{sec:file_close} tutte le operazioni di scrittura
sono in genere bufferizzate dal kernel, che provvede ad effettuarle in maniera
asincrona (ad esempio accorpando gli accessi alla stessa zona del disco) in un
secondo tempo rispetto al momento della esecuzione della \func{write}.
\subsection{La funzioni \func{dup} e \func{dup2}}
\label{sec:file_dup}
-Abbiamo già visto in \secref{sec:file_sharing} come un processo figlio
+Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
condivida gli stessi file descriptor del padre; è possibile però ottenere un
comportamento analogo all'interno di uno stesso processo \textit{duplicando}
un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui
La funzione ritorna, come \func{open}, il primo file descriptor libero. Il
file descriptor è una copia esatta del precedente ed entrambi possono essere
interscambiati nell'uso. Per capire meglio il funzionamento della funzione si
-può fare riferimento a \figref{fig:file_dup}: l'effetto della funzione è
+può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
semplicemente quello di copiare il valore nella struttura
\struct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
alla stessa voce nella \textit{file table}; per questo si dice che il nuovo
\label{fig:file_dup}
\end{figure}
-Si noti che per quanto illustrato in\figref{fig:file_dup} i file descriptor
+Si noti che per quanto illustrato in fig.~\ref{fig:file_dup} i file descriptor
duplicati condivideranno eventuali lock, \textit{file status flag}, e
posizione corrente. Se ad esempio si esegue una \func{lseek} per modificare la
posizione su uno dei due file descriptor, essa risulterà modificata anche
della \textit{file table} a cui entrambi fanno riferimento). L'unica
differenza fra due file descriptor duplicati è che ciascuno avrà il suo
\textit{file descriptor flag}; a questo proposito va specificato che nel caso
-di \func{dup} il flag di \textit{close-on-exec}\index{close-on-exec} (vedi
-\secref{sec:proc_exec} e \secref{sec:file_fcntl}) viene sempre cancellato
+di \func{dup} il flag di \textit{close-on-exec}\itindex{close-on-exec} (vedi
+sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl}) viene sempre cancellato
nella copia.
L'uso principale di questa funzione è per la redirezione dell'input e
dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec};
diventa così possibile associare un file (o una pipe) allo standard input o
-allo standard output (torneremo sull'argomento in \secref{sec:ipc_pipe_use},
+allo standard output (torneremo sull'argomento in sez.~\ref{sec:ipc_pipe_use},
quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
il file che si vuole sostituire, cosicché il suo file descriptor possa esser
restituito alla chiamata di \func{dup}, come primo file descriptor
Dato che questa è l'operazione più comune, è prevista una diversa versione
della funzione, \funcd{dup2}, che permette di specificare esplicitamente
-qual'è il valore di file descriptor che si vuole avere come duplicato; il suo
+qual è il valore di file descriptor che si vuole avere come duplicato; il suo
prototipo è:
\begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
allo stesso valore per il file descriptor).
La duplicazione dei file descriptor può essere effettuata anche usando la
-funzione di controllo dei file \func{fnctl} (che esamineremo in
-\secref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}. L'operazione ha
-la sintassi \code{fnctl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
+funzione di controllo dei file \func{fcntl} (che esamineremo in
+sez.~\ref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}. L'operazione ha
+la sintassi \code{fcntl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
\param{newfd} diventa equivalente a \func{dup}.
La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i
\subsection{La funzione \func{fcntl}}
\label{sec:file_fcntl}
-Oltre alle operazioni base esaminate in \secref{sec:file_base_func} esistono
+Oltre alle operazioni base esaminate in sez.~\ref{sec:file_base_func} esistono
tutta una serie di operazioni ausiliarie che è possibile eseguire su un file
descriptor, che non riguardano la normale lettura e scrittura di dati, ma la
gestione sia delle loro proprietà, che di tutta una serie di ulteriori
funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
- gestiscono con questa funzione l'I/O asincrono (vedi
- \secref{sec:file_asyncronous_io}) e il file locking\index{file!locking}
- (vedi \secref{sec:file_locking}).}
+ gestiscono con questa funzione varie modalità di I/O asincrono (vedi
+ sez.~\ref{sec:file_asyncronous_operation}) e il file
+ locking\index{file!locking} (vedi sez.~\ref{sec:file_locking}).}
-Per queste operazioni di manipolazione e di controllo su proprietà e
-caratteristiche un file descriptor, viene usata la funzione \funcd{fcntl}, il
-cui prototipo è:
+Per queste operazioni di manipolazione e di controllo delle varie proprietà e
+caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl},
+il cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{fcntl.h}
\end{errlist}}
\end{functions}
-Il comportamento di questa funzione è determinato dal valore del comando
-\param{cmd} che le viene fornito; in \secref{sec:file_dup} abbiamo incontrato
-un esempio per la duplicazione dei file descriptor, una lista dei possibili
-valori è riportata di seguito:
+
+Il primo argomento della funzione è sempre il numero di file descriptor
+\var{fd} su cui si vuole operare. Il comportamento di questa funzione, il
+numero e il tipo degli argomenti, il valore di ritorno e gli eventuali errori
+sono determinati dal valore dell'argomento \param{cmd} che in sostanza
+corrisponde all'esecuzione di un determinato \textsl{comando}; in
+sez.~\ref{sec:file_dup} abbiamo incontrato un esempio dell'uso di \func{fcntl}
+per la duplicazione dei file descriptor, una lista di tutti i possibili valori
+per \var{cmd} è riportata di seguito:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{F\_DUPFD}] trova il primo file descriptor disponibile di valore
- maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. In caso di
- successo ritorna il nuovo file descriptor. Gli errori possibili sono
- \errcode{EINVAL} se \param{arg} è negativo o maggiore del massimo consentito
- o \errcode{EMFILE} se il processo ha già raggiunto il massimo numero di
- descrittori consentito.
+ maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. Ritorna il
+ nuovo file descriptor in caso di successo e -1 in caso di errore. Gli errori
+ possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore del
+ massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il
+ massimo numero di descrittori consentito.
\item[\const{F\_SETFD}] imposta il valore del \textit{file descriptor flag} al
valore specificato con \param{arg}. Al momento l'unico bit usato è quello di
- \textit{close-on-exec}\index{close-on-exec}, identificato dalla costante
+ \textit{close-on-exec}\itindex{close-on-exec}, identificato dalla costante
\const{FD\_CLOEXEC}, che serve a richiedere che il file venga chiuso nella
- esecuzione di una \func{exec} (vedi \secref{sec:proc_exec}).
+ esecuzione di una \func{exec} (vedi sez.~\ref{sec:proc_exec}). Ritorna un
+ valore nullo in caso di successo e -1 in caso di errore.
\item[\const{F\_GETFD}] ritorna il valore del \textit{file descriptor flag} di
- \param{fd}, se \const{FD\_CLOEXEC} è impostato i file descriptor aperti
- vengono chiusi attraverso una \func{exec} altrimenti (il comportamento
- predefinito) restano aperti.
-\item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag},
- permette cioè di rileggere quei bit impostati da \func{open} all'apertura del
- file che vengono memorizzati (quelli riportati nella prima e terza sezione
- di \tabref{tab:file_open_flags}).
+ \param{fd} o -1 in caso di errore; se \const{FD\_CLOEXEC} è impostato i file
+ descriptor aperti vengono chiusi attraverso una \func{exec} altrimenti (il
+ comportamento predefinito) restano aperti.
+\item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag} in
+ caso di successo o -1 in caso di errore; permette cioè di rileggere quei bit
+ impostati da \func{open} all'apertura del file che vengono memorizzati
+ (quelli riportati nella prima e terza sezione di
+ tab.~\ref{tab:file_open_flags}).
\item[\const{F\_SETFL}] imposta il \textit{file status flag} al valore
- specificato da \param{arg}, possono essere impostati solo i bit riportati
- nella terza sezione di \tabref{tab:file_open_flags}.\footnote{la pagina di
- manuale riporta come impostabili solo \const{O\_APPEND},
- \const{O\_NONBLOCK} e \const{O\_ASYNC}.}
+ specificato da \param{arg}, ritorna un valore nullo in caso di successo o -1
+ in caso di errore. Possono essere impostati solo i bit riportati nella terza
+ sezione di tab.~\ref{tab:file_open_flags}.\footnote{la pagina di manuale
+ riporta come impostabili solo \const{O\_APPEND}, \const{O\_NONBLOCK} e
+ \const{O\_ASYNC}.}
\item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da
- \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato
- (questa funzionalità è trattata in dettaglio in
- \secref{sec:file_posix_lock}).
+ \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato,
+ ritorna un valore nullo in caso di successo o -1 in caso di errore. Questa
+ funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
\item[\const{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da
qualcun'altro ritorna immediatamente restituendo -1 e imposta \var{errno} a
- \errcode{EACCES} o \errcode{EAGAIN} (questa funzionalità è trattata in
- dettaglio in \secref{sec:file_posix_lock}).
+ \errcode{EACCES} o \errcode{EAGAIN}, in caso di successo ritorna un valore
+ nullo. Questa funzionalità è trattata in dettaglio in
+ sez.~\ref{sec:file_posix_lock}.
\item[\const{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
la funzione non ritorna subito ma attende che il blocco sia rilasciato. Se
l'attesa viene interrotta da un segnale la funzione restituisce -1 e imposta
- \var{errno} a \errcode{EINTR} (questa funzionalità è trattata in dettaglio in
- \secref{sec:file_posix_lock}).
+ \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore nullo.
+ Questa funzionalità è trattata in dettaglio in
+ sez.~\ref{sec:file_posix_lock}.
\item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o
l'identificatore del process group\footnote{i \texttt{process group} sono
- (vedi \secref{sec:sess_proc_group}) sono raggruppamenti di processi usati
- nel controllo di sessione; a ciascuno di essi è associato un
- identificatore (un numero positivo analogo al \acr{pid}).} che è preposto
- alla ricezione dei segnali \const{SIGIO} e \const{SIGURG} per gli eventi
- associati al file descriptor \param{fd}. Nel caso di un process group viene
- restituito un valore negativo il cui valore assoluto corrisponde
- all'identificatore del process group.
+ (vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel
+ controllo di sessione; a ciascuno di essi è associato un identificatore
+ (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione
+ dei segnali \const{SIGIO} e \const{SIGURG} per gli eventi associati al file
+ descriptor \param{fd}. Nel caso di un process group viene restituito un
+ valore negativo il cui valore assoluto corrisponde all'identificatore del
+ process group. In caso di errore viene restituito -1.
\item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
l'identificatore del processo o del \textit{process group} che riceverà i
segnali \const{SIGIO} e \const{SIGURG} per gli eventi associati al file
- descriptor \param{fd}. Come per \const{F\_GETOWN}, per impostare un process
- group si deve usare per \param{arg} un valore negativo, il cui valore
- assoluto corrisponde all'identificatore del process group.
+ descriptor \param{fd}, ritorna un valore nullo in caso di successo o -1 in
+ caso di errore. Come per \const{F\_GETOWN}, per impostare un
+ \textit{process group} si deve usare per \param{arg} un valore negativo, il
+ cui valore assoluto corrisponde all'identificatore del \textit{process
+ group}.
\item[\const{F\_GETSIG}] restituisce il valore del segnale inviato quando ci
sono dati disponibili in ingresso su un file descriptor aperto ed impostato
- per l'I/O asincrono (si veda \secref{sec:file_asyncronous_io}). Il valore 0
+ per l'I/O asincrono (si veda sez.~\ref{sec:file_asyncronous_io}). Il valore 0
indica il valore predefinito (che è \const{SIGIO}), un valore diverso da
zero indica il segnale richiesto, (che può essere anche lo stesso
- \const{SIGIO}).
+ \const{SIGIO}). In caso di errore ritorna -1.
\item[\const{F\_SETSIG}] imposta il segnale da inviare quando diventa
- possibile effettuare I/O sul file descriptor in caso di I/O asincrono. Il
+ possibile effettuare I/O sul file descriptor in caso di I/O asincrono,
+ ritorna un valore nullo in caso di successo o -1 in caso di errore. Il
valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro
- valore (compreso lo stesso \const{SIGIO}) specifica il segnale voluto; l'uso
- di un valore diverso da zero permette inoltre, se si è installato il
- gestore del segnale come \var{sa\_sigaction} usando
- \const{SA\_SIGINFO}, (vedi \secref{sec:sig_sigaction}), di rendere
- disponibili al gestore informazioni ulteriori informazioni riguardo il
- file che ha generato il segnale attraverso i valori restituiti in
- \struct{siginfo\_t} (come vedremo in
- \secref{sec:file_asyncronous_io}).\footnote{i due comandi \const{F\_SETSIG}
- e \const{F\_GETSIG} sono una estensione specifica di Linux.}
+ valore diverso da zero (compreso lo stesso \const{SIGIO}) specifica il
+ segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è
+ installato il gestore del segnale come \var{sa\_sigaction} usando
+ \const{SA\_SIGINFO}, (vedi sez.~\ref{sec:sig_sigaction}), di rendere
+ disponibili al gestore informazioni ulteriori riguardo il file che ha
+ generato il segnale attraverso i valori restituiti in \struct{siginfo\_t}
+ (come vedremo in sez.~\ref{sec:file_asyncronous_io}).\footnote{i due comandi
+ \const{F\_SETSIG} e \const{F\_GETSIG} sono una estensione specifica di
+ Linux.}
+\item[\const{F\_SETLEASE}] imposta o rimuove un \textit{file
+ lease}\footnote{questa è una nuova funzionalità, specifica di Linux, e
+ presente solo a partire dai kernel della serie 2.4.x, in cui il processo
+ che detiene un \textit{lease} su un file riceve una notifica qualora un
+ altro processo cerca di eseguire una \func{open} o una \func{truncate} su
+ di esso.} sul file descriptor \var{fd} a seconda del valore del terzo
+ argomento, che in questo caso è un \ctyp{int}, ritorna un valore nullo in
+ caso di successo o -1 in caso di errore. Questa funzionalità avanzata è
+ trattata in dettaglio in sez.~\ref{sec:file_asyncronous_operation}.
+\item[\const{F\_GETLEASE}] restituisce il tipo di \textit{file lease} che il
+ processo detiene nei confronti del file descriptor \var{fd} o -1 in caso di
+ errore. Con questo comando il terzo argomento può essere omesso. Questa
+ funzionalità avanzata è trattata in dettaglio in
+ sez.~\ref{sec:file_asyncronous_operation}.
+\item[\const{F\_NOTIFY}] attiva un meccanismo di notifica per cui viene
+ riportata al processo chiamante, tramite il segnale \const{SIGIO} (o altro
+ segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
+ direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file
+ in essa contenuti; ritorna un valore nullo in caso di successo o -1 in caso
+ di errore. Questa funzionalità avanzata, disponibile dai kernel della serie
+ 2.4.x, è trattata in dettaglio in sez.~\ref{sec:file_asyncronous_operation}.
\end{basedescript}
La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
-poter essere affrontate in dettaglio a questo punto; saranno riprese più
-avanti quando affronteremo le problematiche ad esse relative (in particolare
-le tematiche relative all'I/O asincrono sono trattate in maniera esaustiva in
-\secref{sec:file_asyncronous_io} mentre quelle relative al \textit{file
- locking}\index{file!locking} saranno esaminate in
-\secref{sec:file_locking}).
+poter essere affrontate in tutti i loro aspetti a questo punto; saranno
+pertanto riprese più avanti quando affronteremo le problematiche ad esse
+relative. In particolare le tematiche relative all'I/O asincrono e ai vari
+meccanismi di notifica saranno trattate in maniera esaustiva in
+sez.~\ref{sec:file_asyncronous_operation} mentre quelle relative al
+\textit{file locking}\index{file!locking} saranno esaminate in
+sez.~\ref{sec:file_locking}).
Si tenga presente infine che quando si usa la funzione per determinare le
modalità di accesso con cui è stato aperto il file (attraverso l'uso del
specifiche di ogni dispositivo particolare, usando come riferimento il solito
file descriptor. Il prototipo di questa funzione è:
\begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
- Manipola il dispositivo sottostante, usando il parametro \param{request} per
- specificare l'operazione richiesta ed il terzo parametro (usualmente di tipo
+ Manipola il dispositivo sottostante, usando l'argomento \param{request} per
+ specificare l'operazione richiesta ed il terzo argomento (usualmente di tipo
\param{char * argp} o \param{int argp}) per il trasferimento
dell'informazione necessaria.
qui riportiamo solo i valori di alcuni comandi che sono definiti per ogni
file:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{FIOCLEX}] Imposta il bit di \textit{close on exec}.
-\item[\const{FIONCLEX}] Cancella il bit di \textit{close on exec}.
+\item[\const{FIOCLEX}] Imposta il flag di
+ \textit{close-on-exec}\itindex{close-on-exec}.
+\item[\const{FIONCLEX}] Cancella il flag di
+ \textit{close-on-exec}\itindex{close-on-exec}.
\item[\const{FIOASYNC}] Abilita l'I/O asincrono.
\item[\const{FIONBIO}] Abilita l'I/O in modalità non bloccante.
\end{basedescript}
projects / gapil.git / blobdiff