tutte le ulteriori operazioni saranno compiute specificando questo stesso
valore come argomento alle varie funzioni dell'interfaccia.
-Per capire come funziona il meccanismo occorre spiegare a grandi linee come è
-che il kernel gestisce l'interazione fra processi e file. Il kernel mantiene
-sempre un elenco dei processi attivi nella cosiddetta \textit{process table}
-ed un elenco dei file aperti nella \textit{file table}.
+Per capire come funziona il meccanismo occorre spiegare a grandi linee come il
+kernel gestisce l'interazione fra processi e file. Il kernel mantiene sempre
+un elenco dei processi attivi nella cosiddetta \textit{process table} ed un
+elenco dei file aperti nella \textit{file table}.
La \textit{process table} è una tabella che contiene una voce per ciascun
processo attivo nel sistema. In Linux ciascuna voce è costituita da una
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 termininale. Lo standard POSIX.1
+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:
\begin{table}[htb]
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 device di
+ \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}). \\
\const{O\_SHLOCK} & opzione di BSD, acquisisce uno shared lock (vedi
\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 dei di accesso dei
+ \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.\\
file con un nome univoco e la funzione \func{link} per verificarne
l'esistenza (vedi \secref{sec:ipc_file_lock}).}
-\footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti
- ad impedire un servizio causando una qualche forma di carico eccessivo per
- il sistema, che resta bloccato nelle risposte all'attacco.}
+\footnotetext[3]{\textit{Denial of Service}\index{DoS}, si chiamano così
+ attacchi miranti ad impedire un servizio causando una qualche forma di
+ carico eccessivo per il sistema, che resta bloccato nelle risposte
+ all'attacco.}
\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
alcune applicazioni per sostituire i file corrispondenti ai file standard
visti in \secref{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}). Il nuovo file descriptor è impostato per restare
-aperto attraverso una \func{exec} (come accennato in \secref{sec:proc_exec}) e
-l'offset è impostato 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
-\secref{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.
+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.
+
+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}
+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.
La funzione prevede diverse opzioni, che vengono specificate usando vari bit
dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire
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
principali:
-\begin{itemize}
+\begin{itemize*}
\item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
si accederà al file: i valori possibili sono lettura, scrittura o
lettura/scrittura. Uno di questi bit deve essere sempre specificato quando
si apre un file. Vengono impostati alla chiamata da \func{open}, e possono
- essere riletti con una \func{fcntl} (fanno parte del \textit{file status
- flag}), ma non possono essere modificati.
+ essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}),
+ ma non possono essere modificati.
\item \textsl{i bit delle modalità di apertura}: permettono di specificare
alcune delle caratteristiche del comportamento di \func{open} quando viene
eseguita. Hanno effetto solo al momento della chiamata della funzione e non
sono memorizzati né possono essere riletti.
\item \textsl{i bit delle modalità di operazione}: permettono di specificare
alcune caratteristiche del comportamento delle future operazioni sul file
- (come la \func{read} o la \func{write}). Anch'essi fanno parte del
- \textit{file status flag}. Il loro valore è impostato alla chiamata di
- \func{open}, ma possono essere riletti e modificati (insieme alle
- caratteristiche operative che controllano) con una \func{fcntl}.
-\end{itemize}
+ (come \func{read} o \func{write}). Anch'essi fan parte del \textit{file
+ status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma
+ possono essere riletti e modificati (insieme alle caratteristiche operative
+ che controllano) con una \func{fcntl}.
+\end{itemize*}
-In \tabref{tab:file_open_flags} si sono riportate, ordinate e divise fra loro
+In \tabref{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 di loro
-con un OR aritmetico per costruire il valore (in forma di maschera binaria)
-dell'argomento \param{flags} da passare alla \func{open} per specificarne il
-comportamento. I due flag \const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono
-estensioni specifiche di Linux, e deve essere definita la macro
-\macro{\_GNU\_SOURCE} per poterli usare.
+ciascuno di questi bit. Dette costanti possono essere combinate fra loro con
+un OR aritmetico per costruire il valore (in forma di maschera binaria)
+dell'argomento \param{flags} da passare alla \func{open}. I due flag
+\const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono estensioni specifiche di
+Linux, e deve essere definita la macro \macro{\_GNU\_SOURCE} per poterli
+usare.
Nelle prime versioni di Unix i valori di \param{flag} specificabili per
\func{open} erano solo quelli relativi alle modalità di accesso del file. Per
Chiude il descrittore \param{fd}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- ed in questo caso \var{errno} assumerà uno dei valori:
+ con \var{errno} che assume i valori:
\begin{errlist}
\item[\errcode{EBADF}] \param{fd} non è un descrittore valido.
\item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\funcdecl{off\_t lseek(int fd, off\_t offset, int whence)}
Imposta la posizione attuale nel file.
- \bodydesc{La funzione ritorna valore della posizione corrente in caso di
+ \bodydesc{La funzione ritorna il valore della posizione corrente in caso di
successo e -1 in caso di errore nel qual caso \var{errno} assumerà uno dei
valori:
\begin{errlist}
Come accennato in \secref{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 nessuna
-attività di input/output, si limita a modificare la posizione corrente nel
-kernel (cioè \var{f\_pos} in \param{file}, vedi \figref{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)}.
+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
+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)}.
Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che
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
+\textit{race condition}\index{race condition}, vedi \secref{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
\label{sec:file_read}
-Una volta che un file è stato aperto (con il permesso in lettura) su possono
+Una volta che un file è stato aperto (con il permesso in lettura) si possono
leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui
prototipo è:
\begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
La funzione tenta di leggere \param{count} byte a partire dalla posizione
corrente nel file. Dopo la lettura la posizione sul file è spostata
automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
-funzione restituisce zero senza nessun altro risultato.
-
-Si deve sempre tener presente che non è detto che la funzione \func{read}
-restituisca sempre il numero di byte richiesto, ci sono infatti varie ragioni
-per cui la funzione può restituire un numero di byte inferiore; questo è un
-comportamento normale, e non un errore, che bisogna sempre tenere presente.
+funzione restituisce zero senza nessun altro risultato. Si deve sempre tener
+presente che non è detto che la funzione \func{read} restituisca sempre il
+numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione
+può restituire un numero di byte inferiore; questo è un comportamento normale,
+e non un errore, che bisogna sempre tenere presente.
La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
di quanto il file ne contenga. In questo caso il file viene letto fino alla
sua fine, e la funzione ritorna regolarmente il numero di byte letti
-effettivamente.
-
-Raggiunta la fine del file, alla ripetizione di un'operazione di lettura,
-otterremmo il ritorno immediato di \func{read} con uno zero. La condizione di
-raggiungimento della fine del file non è un errore, e viene segnalata appunto
-da un valore di ritorno di \func{read} nullo. Ripetere ulteriormente la
-lettura non avrebbe nessun effetto se non quello di continuare a ricevere zero
-come valore di ritorno.
+effettivamente. Raggiunta la fine del file, alla ripetizione di un'operazione
+di lettura, otterremmo il ritorno immediato di \func{read} con uno zero. La
+condizione di raggiungimento della fine del file non è un errore, e viene
+segnalata appunto da un valore di ritorno di \func{read} nullo. Ripetere
+ulteriormente la lettura non avrebbe nessun effetto se non quello di
+continuare a ricevere zero come valore di ritorno.
Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
un numero di byte letti inferiore a quello richiesto, ma questo non è vero
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
lettura da certi file di dispositivo, come le unità a nastro, che
-restituiscono sempre i dati ad un singolo blocco alla volta.
+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
+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{sotto
- BSD per questo errore viene usata la costante \errcode{EWOULDBLOCK}, in
- Linux, con le glibc, questa è sinonima di \errcode{EAGAIN}.} che indica
-soltanto che occorrerà provare a ripetere la lettura.
+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.
La funzione \func{read} è una delle system call fondamentali, esistenti fin
dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix
\end{prototype}
\noindent che però diventa accessibile solo con la definizione della macro:
\begin{verbatim}
- #define _XOPEN_SOURCE 500
+#define _XOPEN_SOURCE 500
\end{verbatim}
Questa funzione serve quando si vogliono leggere dati dal file senza
chiuso in lettura; in questo caso viene anche generato il segnale
\const{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
funzione ritorna questo errore.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
- aver potuto scrivere qualsiasi dato.
- \item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
- era aperto il file in modalità \const{O\_NONBLOCK}.
+ \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
+ potuto scrivere qualsiasi dato.
+ \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
+ modalità \const{O\_NONBLOCK}.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
\errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori
\label{fig:file_mult_acc}
\end{figure}
-Il primo caso è quello in cui due processi diversi che aprono lo stesso file
+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
processo avrà una sua voce nella \textit{file table} referenziata da un
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},
quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
-il file che si vuole sostituire, cossicché il suo file descriptor possa esser
+il file che si vuole sostituire, cosicché il suo file descriptor possa esser
restituito alla chiamata di \func{dup}, come primo file descriptor
disponibile.
la sintassi \code{fnctl(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 sistassi ed i
+La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i
diversi codici di errore.} è che \func{dup2} chiude il file descriptor
\param{newfd} se questo è già aperto, garantendo che la duplicazione sia
effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
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
- gesticono con questa funzione l'I/O asincrono (vedi
+ 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}).}
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
-comando \const{F\_GETFL}) è necessario estrarre i bit corripondenti nel
+comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
\textit{file status flag} che si è ottenuto. Infatti la definizione corrente
di quest'ultimo non assegna bit separati alle tre diverse modalità
\const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
projects / gapil.git / blobdiff