Esamineremo in questo capitolo le due interfacce di programmazione che
consentono di gestire i dati mantenuti nei file. Cominceremo con quella nativa
-del sistema, detta dei \itindex{file~descriptor} \textit{file descriptor}, che
-viene fornita direttamente dalle \textit{system call} e che non prevede
-funzionalità evolute come la bufferizzazione o funzioni di lettura o scrittura
+del sistema, detta dei \textit{file descriptor}, che viene fornita
+direttamente dalle \textit{system call} e che non prevede funzionalità evolute
+come la bufferizzazione o funzioni di lettura o scrittura
formattata. Esamineremo poi anche l'interfaccia definita dallo standard ANSI
C, che viene chiamata dei \textit{file stream} o anche più brevemente degli
\textit{stream}. Per entrambe dopo una introduzione alle caratteristiche
esistono con Linux.} Uno di questi, \const{O\_EXCL}, ha senso solo se usato
in combinazione a \const{O\_CREAT} quando si vuole creare un nuovo file per
assicurarsi che questo non esista di già, e lo si usa spesso per creare i
-cosiddetti \index{file!di lock} ``\textsl{file di lock}'' (vedi
-sez.~\ref{sec:ipc_file_lock}). Si tenga presente che questa opzione è
-supportata su NFS solo a partire da NFSv3 e con il kernel 2.6, nelle versioni
-precedenti la funzionalità viene emulata controllando prima l'esistenza del
-file per cui usarla per creare \index{file!di lock} un file di lock potrebbe
-dar luogo a una \textit{race condition}.\footnote{un file potrebbe venir
- creato fra il controllo la successiva apertura con \const{O\_CREAT}, la cosa
- si può risolvere comunque creando un file con un nome univoco ed usando la
- funzione \func{link} per creare il \index{file!di lock} file di lock, (vedi
- sez.~\ref{sec:ipc_file_lock}).}
+cosiddetti ``\textsl{file di lock}'' (vedi sez.~\ref{sec:ipc_file_lock}). Si
+tenga presente che questa opzione è supportata su NFS solo a partire da NFSv3
+e con il kernel 2.6, nelle versioni precedenti la funzionalità viene emulata
+controllando prima l'esistenza del file per cui usarla per creare un file di
+lock potrebbe dar luogo a una \textit{race condition}.\footnote{un file
+ potrebbe venir creato fra il controllo la successiva apertura con
+ \const{O\_CREAT}, la cosa si può risolvere comunque creando un file con un
+ nome univoco ed usando la funzione \func{link} per creare il file di lock,
+ (vedi sez.~\ref{sec:ipc_file_lock}).}
Se si usa \const{O\_EXCL} senza \const{O\_CREAT} il comportamento è
indefinito. Nella creazione di un file con \const{O\_CREAT} occorre sempre
\itindbeg{at-functions}
Un problema generale che si pone con l'uso della funzione \func{open}, così
-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 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 \textit{race condition} in cui
-c'è spazio per un \textit{symlink attack} (si ricordi quanto visto per
-\func{access} in sez.~\ref{sec:file_perm_management}).
+come per le altre funzioni che prendono come argomenti dei \textit{pathname}
+relativi, è la possibilità, quando un \textit{pathname} relativo non fa
+riferimento ad un file posto 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 \textit{race condition} in cui c'è spazio per un \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
\func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
funzioni, dette anche ``\textit{at-functions}'' in quanto contraddistinte dal
suffisso \texttt{at}, che permettono l'apertura di un file (o le rispettive
-altre operazioni) usando un \itindsub{pathname}{relativo} \textit{pathname}
-relativo ad una directory specificata.\footnote{l'introduzione è avvenuta su
- proposta dello sviluppatore principale della \acr{glibc} Urlich Drepper e le
- corrispondenti \textit{system call} sono state inserite nel kernel a partire
- dalla versione 2.6.16, in precedenza era disponibile una emulazione che, sia
- pure con prestazioni inferiori, funzionava facendo ricorso all'uso del
- filesystem \textit{proc} con l'apertura del file attraverso il riferimento a
+altre operazioni) usando un \textit{pathname} relativo ad una directory
+specificata.\footnote{l'introduzione è avvenuta su proposta dello sviluppatore
+ principale della \acr{glibc} Urlich Drepper e le corrispondenti
+ \textit{system call} sono state inserite nel kernel a partire dalla versione
+ 2.6.16, in precedenza era disponibile una emulazione che, sia pure con
+ prestazioni inferiori, funzionava facendo ricorso all'uso del filesystem
+ \textit{proc} con l'apertura del file attraverso il riferimento a
\textit{pathname} del tipo di \texttt{/proc/self/fd/dirfd/relative\_path}.}
Benché queste funzioni non siano presenti negli standard tradizionali esse
-sono state adottate da altri sistemi unix-like come Solaris, i vari BSD, fino ad
-essere incluse in una recente revisione (la POSIX.1-2008) dello standard
+sono state adottate da altri sistemi unix-like come Solaris, i vari BSD, fino
+ad essere incluse in una recente revisione (la POSIX.1-2008) dello standard
POSIX.1. Con la \acr{glibc} per l'accesso a queste funzioni è necessario
definire la macro \macro{\_ATFILE\_SOURCE}.
L'uso di queste funzioni prevede una apertura iniziale della directory che
-sarà la base della risoluzione dei \itindsub{pathname}{relativo}
-\textit{pathname} relativi che verranno usati in seguito, dopo di che si dovrà
-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
-directory di lavoro diversa per ciascuno di essi.
+sarà la base della risoluzione dei \textit{pathname} relativi che verranno
+usati in seguito, dopo di che si dovrà 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 directory di lavoro diversa per ciascuno
+di essi.
Questo metodo, oltre a risolvere i problemi di \textit{race condition},
consente anche di ottenere aumenti di prestazioni significativi quando si
\func{open}, ed in più:
\begin{errlist}
\item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
- \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
- \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
\end{errlist}
}
\end{funcproto}
Il comportamento delle nuove funzioni è del tutto analogo a quello delle
corrispettive classiche, con la sola eccezione del fatto che se fra i loro
-argomenti si utilizza un \itindsub{pathname}{relativo} \textit{pathname}
-relativo questo sarà risolto rispetto alla directory indicata
-da \param{dirfd}. Qualora invece si usi un \itindsub{pathname}{assoluto}
+argomenti si utilizza un \textit{pathname} relativo questo sarà risolto
+rispetto alla directory indicata da \param{dirfd}. Qualora invece si usi un
\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 lavoro corrente del
particolare si avrà un errore di \errcode{EBADF} se esso non è un file
descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa
riferimento ad una directory, tranne il caso in cui si sia specificato un
-\itindsub{pathname}{assoluto} \textit{pathname} assoluto, nel qual caso, come
-detto, il valore di \param{dirfd} sarà completamente ignorato.
+\textit{pathname} assoluto, nel qual caso, come detto, il valore
+di \param{dirfd} sarà completamente ignorato.
\begin{table}[htb]
\centering
\begin{errlist}
\item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
- \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
- \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
\end{errlist}
}
\end{funcproto}
\begin{errlist}
\item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
- \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
- \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
\end{errlist}
}
\end{funcproto}
\begin{errlist}
\item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
- \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
- \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
\end{errlist}
}
\end{funcproto}
projects / gapil.git / blobdiff