per \param{size} o si è usato \const{O\_DIRECT} ed il buffer non è
allineato.
\item[\errval{EIO}] si è tentata la lettura dal terminale di controllo
- essendo in background (vedi sez.~\ref{sec:term_io_design}).
+ essendo in background ignorando o bloccando \const{SIGTTIN} (vedi
+ sez.~\ref{sec:term_io_design}) o per errori di basso livello sul supporto.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EFAULT} e \errval{EISDIR}, nel loro
significato generico.}
\end{funcproto}
La funzione tenta di leggere \param{count} byte dal file \param{fd} a partire
-dalla posizione corrente, scrivendoli nel buffer \param{buf}. 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. Inoltre che non è detto che la funzione \func{read} restituisca 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.
+dalla posizione corrente, scrivendoli nel buffer \param{buf}.\footnote{fino ad
+ un massimo di \const{0x7ffff000} byte, indipendentemente che l'architettura
+ sia a 32 o 64 bit.} 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. Inoltre che non è
+detto che la funzione \func{read} restituisca 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
di dispositivo, come le unità a nastro, che 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, o i terminali, per i quali si
-applicano inoltre ulteriori condizioni che approfondiremo in
+applicano anche ulteriori condizioni che approfondiremo in
sez.~\ref{sec:sess_terminal_io}.
Infine anche le due condizioni segnalate dagli errori \errcode{EINTR} ed
La funzione prende esattamente gli stessi argomenti di \func{read} con lo
stesso significato, a cui si aggiunge l'argomento \param{offset} che indica
-una posizione sul file. Identico è 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
+una posizione sul file a partire dalla quale verranno i \param{count}
+byte. Identico è il comportamento ed il valore di ritorno, ma la posizione
+corrente sul file resterà invariata. Il valore di \param{offset} fa sempre
+riferimento all'inizio del file.
+
+L'uso di \func{pread} è equivalente all'esecuzione di una \func{lseek} alla
+posizione indicata da \param{offset} seguita da una \func{read}, seguita da
+un'altra \func{lseek} che riporti al valore iniziale della 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_shared_access}). Il valore di \param{offset} fa
-sempre riferimento all'inizio del file.
+(vedi sez.~\ref{sec:file_shared_access}) ed è particolarmente utile in caso di
+programmazione \textit{multi-thread} (vedi sez.~\ref{cha:threads}) quando
+all'interno di un processo si vuole che le operazioni di un \textit{thread}
+non possano essere influenzata da eventuali variazioni della posizione sul
+file effettuate da altri \textit{thread}.
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{Example}
-#define _XOPEN_SOURCE 500
-\end{Example}
-e si ricordi di definire questa macro prima dell'inclusione del file di
-dichiarazioni \headfile{unistd.h}.
-
+\textit{Single Unix Specification} con un valore della macro
+\macro{\_XOPEN\_SOURCE} maggiore o uguale a 500 o a partire dalla \acr{glibc}
+2.12 con un valore dalla macro \macro{\_POSIX\_C\_SOURCE} maggiore o uguale al
+valore \val{200809L}. Si ricordi di definire queste macro prima
+dell'inclusione del file di dichiarazione \headfile{unistd.h}.
\subsection{Le funzioni per la scrittura di un file}
indicato da \param{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 un'analoga \funcd{pwrite}
-per scrivere alla posizione indicata senza modificare la posizione corrente
-nel file, il suo prototipo è:
+Anche per \func{write} lo standard Unix98 (ed i successivi POSIX.1-2001 e
+POSIX.1-2008) definiscono un'analoga \funcd{pwrite} per scrivere alla
+posizione indicata senza modificare la posizione corrente nel file, il suo
+prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
\func{write} e \func{lseek}.}
\end{funcproto}
-\noindent e per essa valgono le stesse considerazioni fatte per \func{pread}.
+\noindent per questa funzione valgono le stesse considerazioni fatte per
+\func{pread}, a cui si aggiunge il fatto che su Linux, a differenza di quanto
+previsto dallo standard POSIX che richiederebbe di ignorarlo, se si è aperto
+il file con \const{O\_APPEND} i dati saranno comunque scritti in coda al file,
+ignorando il valore di \param{offset}.
\section{Caratteristiche avanzate}
\begin{figure}[!htb]
\centering
- \includegraphics[width=12cm]{img/filemultacc}
+ \includegraphics[width=11cm]{img/filemultacc}
\caption{Schema dell'accesso allo stesso file da parte di due processi
diversi}
\label{fig:file_mult_acc}
\end{figure}
-Il primo caso è quello in cui due processi diversi aprono lo stesso file su
-disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
+Il primo caso è quello in cui due processi indipendenti aprono lo stesso file
+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 \kstruct{file\_struct}. Entrambe le voci
vengono mantenute nella sua voce della \textit{file table}. Questo ha
conseguenze specifiche sugli effetti della possibile azione simultanea sullo
stesso file, in particolare occorre tenere presente che:
-\begin{itemize}
+\begin{itemize*}
\item ciascun processo può scrivere indipendentemente, dopo ciascuna
\func{write} la posizione corrente sarà cambiata solo nel processo
scrivente. Se la scrittura eccede la dimensione corrente del file questo
\item se un file è in modalità \const{O\_APPEND} tutte le volte che viene
effettuata una scrittura la posizione corrente viene prima impostata alla
dimensione corrente del file letta dalla struttura \kstruct{inode}. Dopo la
- scrittura il file viene automaticamente esteso.
+ scrittura il file viene automaticamente esteso. Questa operazione avviene
+ atomicamente, ogni altro processo che usi \const{O\_APPEND} vedrà la
+ dimensione estesa e continuerà a scrivere in coda al file.
\item l'effetto di \func{lseek} è solo quello di cambiare il campo
\var{f\_pos} nella struttura \kstruct{file} della \textit{file table}, non
c'è nessuna operazione sul file su disco. Quando la si usa per porsi alla
- fine del file la posizione viene impostata leggendo la dimensione corrente
- dalla struttura \kstruct{inode}.
-\end{itemize}
+ fine del file la posizione viene impostata leggendo la attuale dimensione
+ corrente dalla struttura \kstruct{inode}.
+\end{itemize*}
\begin{figure}[!htb]
\centering
- \includegraphics[width=12cm]{img/fileshar}
+ \includegraphics[width=11cm]{img/fileshar}
\caption{Schema dell'accesso ai file da parte di un processo figlio}
\label{fig:file_acc_child}
\end{figure}
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
+puntano 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 sez.~\ref{sec:proc_fork}). La
situazione è illustrata in fig.~\ref{fig:file_acc_child}; dato che il processo
Si tenga presente dunque che in un sistema unix-like è sempre possibile per
più processi accedere in contemporanea allo stesso file e che non esistono, a
differenza di altri sistemi operativi, dei meccanismi di blocco o di
-restrizione dell'accesso impliciti se più processi vogliono accedere allo
+restrizione dell'accesso impliciti quando più processi vogliono accedere allo
stesso file. Questo significa che le operazioni di lettura e scrittura vengono
-sempre fatte da ogni processo in maniera autonoma, utilizzando una posizione
-corrente nel file che normalmente (a meno di non trovarsi nella situazione di
-fig.~\ref{fig:file_acc_child}) è locale a ciascuno di essi.
+sempre fatte da ogni processo in maniera indipendente, utilizzando una
+posizione corrente nel file che normalmente, a meno di non trovarsi nella
+situazione di fig.~\ref{fig:file_acc_child}, è locale a ciascuno di essi.
Dal punto di vista della lettura dei dati questo comporta la possibilità di
poter leggere dati non coerenti in caso di scrittura contemporanea da parte di
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 sez.~\ref{sec:file_lseek} impostare la posizione alla
-fine del file e poi scrivere può condurre ad una \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 primo processo, avrà una posizione corrente che aveva
-impostato con la \func{lseek} che non corrisponde più alla fine del file, e la
-sua successiva \func{write} sovrascriverà i dati del secondo processo.
+fine del file con \func{lseek} e poi scrivere con \func{write} può condurre ad
+una \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 primo processo,
+avrà una posizione corrente che aveva impostato con \func{lseek} che non
+corrisponde più alla fine del file, e la sua successiva \func{write}
+sovrascriverà i dati del secondo processo.
Il problema deriva dal fatto che usare due \textit{system call} in successione
non è mai un'operazione atomica dato che il kernel può interrompere
Abbiamo già visto in sez.~\ref{sec:file_shared_access} 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 di sistema \funcd{dup},
-il cui prototipo è:
+comportamento analogo all'interno di uno stesso processo con la cosiddetta
+\textit{duplicazione} di un file descriptor. Per far questo si usa la funzione
+di sistema \funcd{dup}, il cui prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
\begin{errlist}
\item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
\item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
- descriptor aperti.
+ descriptor aperti (vedi sez.~\ref{sec:sys_resource_limit}).
\end{errlist}
}
\end{funcproto}
da cui il nome della funzione.
\begin{figure}[!htb]
- \centering \includegraphics[width=12cm]{img/filedup}
+ \centering \includegraphics[width=11cm]{img/filedup}
\caption{Schema dell'accesso ai file duplicati}
\label{fig:file_dup}
\end{figure}
file vi si vuole far corrispondere, invece di duplicare un file descriptor che
si è già aperto. La risposta sta nel fatto che il file che si vuole redirigere
non è detto sia un file regolare, ma potrebbe essere, come accennato, anche
-una \textit{fifo} o un socket, oppure potrebbe essere un file associato ad un file
-descriptor che si è ereditato già aperto (ad esempio attraverso un'altra
+una \textit{fifo} o un socket, oppure potrebbe essere un file associato ad un
+file descriptor che si è ereditato già aperto (ad esempio attraverso una
\func{exec}) da un processo antenato del padre, del quale non si conosce il
nome. Operando direttamente con i file descriptor \func{dup} consente di
ignorare le origini del file descriptor che si duplica e funziona in maniera
Come accennato in sez.~\ref{sec:file_open_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
+disco in un secondo tempo rispetto al momento della esecuzione della
\func{write}.
Per questo motivo quando è necessaria una sincronizzazione dei dati il sistema
\end{funcproto}
I vari standard prevedono che la funzione si limiti a far partire le
-operazioni, ritornando immediatamente, con Linux fin dal kernel 1.3.20 invece
+operazioni ritornando immediatamente, con Linux invece, fin dal kernel 1.3.20,
la funzione aspetta la conclusione delle operazioni di sincronizzazione. Si
tenga presente comunque che questo non dà la garanzia assoluta che i dati
siano integri dopo la chiamata, l'hardware dei dischi è in genere dotato di un
-suo meccanismo interno di bufferizzazione che può ritardare ulteriormente la
-scrittura effettiva.
+suo meccanismo interno di bufferizzazione che a sua volta può ritardare
+ulteriormente la scrittura effettiva.
La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
esplicitamente lo scarico dei dati su disco, un tempo era invocata da un
apposito demone di sistema (in genere chiamato \cmd{update}) che eseguiva lo
scarico dei dati ad intervalli di tempo fissi. Con le nuove versioni del
kernel queste operazioni vengono gestite direttamente dal sistema della
-memoria virtuale, attraverso opportuni \textit{task} interni al kernel il cui
-comportamento può essere controllato attraverso il file
-\sysctlfiled{vm/bdflush}.\footnote{per il significato dei valori che si possono
- scrivere in questo file si consulti la documentazione allegata ai sorgenti
- del kernel nel file \file{Documentation/sysctl/vm.txt}, trattandosi di
- argomenti di natura sistemistica non li prenderemo in esame.} Si tenga
-presente che la funzione di sistema \funcm{bdflush}, che un tempo veniva usata
-per queste impostazioni, è deprecata e causa semplicemente la stampa di un
-messaggio nei log del kernel, pertanto non la prenderemo in esame.
+memoria virtuale, attraverso opportuni \textit{task} interni al kernel. Nei
+kernel recenti questo comportamento può essere controllato con l'uso dei vari
+file \texttt{dirty\_*} in \sysctlfiled{vm/}.\footnote{si consulti la
+ documentazione allegata ai sorgenti del kernel nel file
+ \file{Documentation/sysctl/vm.txt}, trattandosi di argomenti di natura
+ sistemistica non li prenderemo in esame.}
+
+Si tenga presente che la funzione di sistema \funcm{bdflush}, che un tempo
+veniva usata per controllare lo scaricamento dei dati, è deprecata a partire
+dal kernel 2.6 e causa semplicemente la stampa di un messaggio nei log del
+kernel, e non è più presente dalle \acr{glibc} 2.23, pertanto non la
+prenderemo in esame.
Quando si vogliano scaricare i dati di un singolo file, ad esempio essere
sicuri che i dati di un database siano stati registrati su disco, si possono
{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{EDQUOT}] si è superata un quota disco durante la
+ sincronizzazione.
\item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
+ sincronizzazione (talvolta anche \errval{EROFS}).
+ \item[\errcode{EIO}] c'è stato un errore di I/O durante la sincronizzazione,
+ che in questo caso può derivare anche da scritture sullo stesso file
+ eseguite su altri file descriptor.
+ \item[\errcode{ENOSPC}] si è esaurito lo spazio disco durante la
sincronizzazione.
\end{errlist}
- ed inoltre \errval{EBADF}, \errval{EIO} e \errval{EROFS} nel loro
- significato generico.}
+ ed inoltre \errval{EBADF} nel suo significato generico.}
\end{funcproto}
Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
con l'opzione \cmd{sync}, il kernel provvede anche alla sincronizzazione
automatica delle voci delle directory.}
+La funzione può restituire anche \errval{ENOSPC} e \errval{EDQUOT} per quei
+casi in cui l'allocazione dello spazio disco non viene effettuata
+all'esecuzione di una \func{write} (come NFS o altri filesystem di rete) per
+cui l'errore viene rilevato quando la scrittura viene effettivamente
+eseguita.
+
L'uso di \func{sync} presenta in certi casi, quando ci sono più filesystem
montati, problemi di prestazioni dovute al fatto che la funzione provoca la
sincronizzazione dei dati su tutti quanti i filesystem, anche quando
\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 \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}).
+Un problema generico che si pone con l'uso della funzione \func{open}, così
+come con le altre funzioni che prendono come argomenti dei \textit{pathname},
+è la possibilità, quando si usa un \textit{pathname} che non fa riferimento
+diretto ad un file posto nella directory di lavoro corrente, che alcuni dei
+componenti dello stesso 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
-\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.
+associata al singolo processo; questo significa che quando si lavora con i
+\textit{thread} questa sarà sempre la stessa per tutti \textit{thread}, ed un
+cabiamento di directory di lavoro effettuato all'interno di un \textit{thread}
+verrà applicato a tutti, non esiste quindi con le funzioni classiche un modo
+semplice per far si che i singoli \textit{thread} possano aprire file usando
+una propria directory per risolvere i \textit{pathname} relativi.
Per risolvere questi problemi, riprendendo una interfaccia già presente in
Solaris, a fianco delle normali funzioni che operano sui file (come
\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 \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
+funzioni di sistema, chiamate ``\textit{at-functions}'' in quanto quasi tutte
+sono contraddistinte dal suffisso \texttt{at}, che permettono l'apertura di un
+file (o le rispettive 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
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 \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 \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
-devono eseguire molte operazioni su sezioni dell'albero dei file che prevedono
-delle gerarchie di sottodirectory molto profonde. Infatti in questo caso basta
-eseguire la risoluzione del \textit{pathname} della directory di partenza una
-sola volta (nell'apertura iniziale) e non tutte le volte che si deve accedere
-a ciascun file che essa contiene.
-
-La sintassi generale di queste nuove funzioni è che esse prevedono come primo
-argomento il file descriptor della directory da usare come base per la
+definire la macro \macro{\_ATFILE\_SOURCE} (attiva di default).
+
+L'uso di queste funzioni prevede una apertura iniziale della directory che si
+intende usare come base per la risoluzione dei \textit{pathname} relativi,
+dopo di che si dovrà passare il suddetto file descriptor alle stesse, che
+useranno quella directory come punto di partenza per la risoluzione. In questo
+modo, anche quando si lavora con i \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} dovuti
+al possibile cambiamento di uno dei componenti del \textit{pathname}, consente
+anche di ottenere aumenti di prestazioni significativi quando si devono
+eseguire molte operazioni su sezioni dell'albero dei file che prevedono delle
+gerarchie di sottodirectory molto profonde. Infatti in questo caso basta
+eseguire la risoluzione del \textit{pathname} di una qualunque directory di
+partenza una sola volta (nell'apertura iniziale) e non tutte le volte che si
+deve accedere a ciascun file che essa contiene.
+
+La sintassi generale di queste nuove funzioni è l'utilizzo come primo
+argomento del file descriptor della directory da usare come base per la
risoluzione dei nomi, mentre gli argomenti successivi restano identici a
-quelli della corrispondente funzione ordinaria. Se ad esempio prendiamo in
-esame la nuova funzione di sistema \funcd{openat}, avremo il prototipo:
+quelli della corrispondente funzione ordinaria. Come esempio prendiamo in
+esame la nuova funzione di sistema \funcd{openat}, il cui prototipo è:
\begin{funcproto}{
\fhead{fcntl.h}
}
\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 \textit{pathname} relativo questo sarà risolto
-rispetto alla directory indicata da \param{dirfd}. Qualora invece si usi un
+Il comportamento di \func{openat} è del tutto analogo a quello di \func{open},
+con la sola eccezione del fatto che se per l'argomento \pathname{pathname} 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 \constd{AT\_FDCWD}, la
risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
usare occorrerà includere comunque questo file, anche per le funzioni che non
sono definite in esso.
+Si tenga comunque presente che l'uso di \func{openat} non risolve in generale
+tutte le possibili \textit{race condition} legati all'apertura di un file,
+dopo un eventuale controllo di accesso o esistenza, ma consente comunque di
+difendersi da tutti gli attacchi eseguiti modificando le componenti superiori
+del suo \textit{pathname}. Inoltre una ...
+
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
\textbf{Funzione} &\textbf{Flags} &\textbf{Corrispondente} \\
\hline
\hline
+ \func{execveat} &$\bullet$&\func{execve} \\
\func{faccessat} &$\bullet$&\func{access} \\
\funcm{fchmodat} &$\bullet$&\func{chmod} \\
\func{fchownat} &$\bullet$&\func{chown},\func{lchown}\\
\funcm{fstatat} &$\bullet$&\func{stat},\func{lstat} \\
- \func{utimensat} &$\bullet$&\func{utimes},\func{lutimes}\\
\func{linkat} &$\bullet$\footnotemark&\func{link} \\
\funcm{mkdirat} & -- &\func{mkdir} \\
+ \funcm{mkfifoat} & -- &\func{mkfifo} \\
\funcm{mknodat} & -- &\func{mknod} \\
\func{openat} & -- &\func{open} \\
\funcm{readlinkat}& -- &\func{readlink}\\
\funcm{renameat} & -- &\func{rename} \\
+ \funcm{statx} &$\bullet$&\func{stat} \\
\funcm{symlinkat}& -- &\func{symlink} \\
\func{unlinkat} &$\bullet$&\func{unlink},\func{rmdir} \\
- \funcm{mkfifoat} & -- &\func{mkfifo} \\
+ \func{utimensat} &$\bullet$&\func{utimes},\func{lutimes}\\
\hline
\end{tabular}
\caption{Corrispondenze fra le nuove funzioni ``\textit{at}'' e le
anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
-
-
% TODO trattare fstatat e con essa
% TODO trattare anche statx, aggiunta con il kernel 4.11 (vedi
% https://lwn.net/Articles/707602/ e
%%% TeX-master: "gapil"
%%% End:
-% LocalWords: nell' du vm Documentation Urlich Drepper futimesat times
+% LocalWords: nell' du vm Documentation Urlich Drepper futimesat times l'I
% LocalWords: futimens fs Tread all'I ll TMPFILE EDQUOT extN Minix UDF XFS
% LocalWords: shmem Btrfs ubifs tmpfile fchmod fchown fsetxattr fchdir PF
-% LocalWords: fstatfs sull'
+% LocalWords: fstatfs sull' SIGTTIN EDESTADDRREQ datagram connect
projects / gapil.git / blobdiff