-%% fileio.tex (merge fileunix.tex - filestd.tex)
+s%% fileio.tex (merge fileunix.tex - filestd.tex)
%%
-%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2019 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 "Un preambolo",
\chapter{La gestione dell'I/O su file}
\label{cha:file_IO_interface}
-Esamineremo in questo capitol le due interfacce di programmazione che
+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 \textit{file descriptor}, che viene fornita
direttamente dalle \textit{system call} e che non prevede funzionalità evolute
\itindend{file~descriptor}
-Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte
-delle applicazioni, e non aderirvi potrebbe portare a problemi di
+Benché questa sia alla fine soltanto una convenzione, essa è seguita dalla
+totalità delle applicazioni, e non aderirvi potrebbe portare a problemi di
interoperabilità. 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
analoga di quella delle voci di una directory, con la possibilità di avere più
voci che fanno riferimento allo stesso \textit{inode}. L'analogia è in realtà
molto stretta perché quando si cancella un file, il kernel verifica anche che
-non resti nessun riferimento in una una qualunque voce della \textit{file
- table} prima di liberare le risorse ad esso associate e disallocare il
-relativo \textit{inode}.
+non resti nessun riferimento in una qualunque voce della \textit{file table}
+prima di liberare le risorse ad esso associate e disallocare il relativo
+\textit{inode}.
Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
numero di file aperti era anche soggetto ad un limite massimo dato dalle
\const{O\_CREAT} e \const{O\_EXCL}.
\item[\errcode{EINTR}] la funzione era bloccata ed è stata interrotta da un
segnale (vedi sez.~\ref{sec:sig_gen_beha}).
- \item[\errcode{EISDIR}] \param{pathname} indica una directory e si è tentato
- l'accesso in scrittura o in lettura/scrittura.
- \item[\errcode{EFBIG}] il file è troppo grande per essere aperto (lo
- standard richiederebbe \errval{EOVERFLOW}).
+ \item[\errcode{EINVAL}] si è usato \const{O\_CREAT} indicando un pathname
+ con caratteri non supportati dal filesystem sottostante o si è richiesto
+ \const{O\_TMPFILE} senza indicare \const{O\_WRONLY} o \const{O\_RDWR} o si
+ è usato \const{O\_DIRECT} per un filesystem che non lo supporta.
+ \item[\errcode{EISDIR}] \param{pathname} indica una directory e o si è
+ tentato un accesso che prevede la scrittura o si è usato
+ \const{O\_TMPFILE} con accesso che prevede la scrittura ma il kernel non
+ supporta la funzionalità.
+ \item[\errcode{EFBIG}] il file è troppo grande per essere aperto, in genere
+ dovuto al fatto che si è compilata una applicazione a 32 bit senza
+ abilitare il supporto per le dimensioni a 64 bit; questo è il valore
+ restituito fino al kernel 2.6.23, coi successivi viene restituito
+ \errcode{EOVERFLOW} come richiesto da POSIX.1.
\item[\errcode{ELOOP}] si sono incontrati troppi collegamenti simbolici nel
risolvere \param{pathname} o si è indicato \const{O\_NOFOLLOW} e
- \param{pathname} è un collegamento simbolico.
+ \param{pathname} è un collegamento simbolico (e non si è usato
+ \const{O\_PATH}).
\item[\errcode{ENODEV}] \param{pathname} si riferisce a un file di
dispositivo che non esiste.
\item[\errcode{ENOENT}] \param{pathname} non esiste e non si è richiesto
- \const{O\_CREAT}, o non esiste un suo componente.
+ \const{O\_CREAT}, o non esiste un suo componente, o si riferisce ad una
+ directory inesistente, si è usato \const{O\_TMPFILE} con accesso che
+ prevede la scrittura ma il kernel non supporta la funzionalità.
\item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
\param{pathname} non è una directory.
\item[\errcode{ENXIO}] si sono impostati \const{O\_NONBLOCK} o
- \const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
- processo o \param{pathname} è un file di dispositivo ma il dispositivo è
- assente.
+ \const{O\_WRONLY} ed il file è una \textit{fifo} che non viene letta da
+ nessun processo o \param{pathname} è un file di dispositivo ma il
+ dispositivo è assente.
\item[\errcode{EPERM}] si è specificato \const{O\_NOATIME} e non si è né
amministratori né proprietari del file.
\item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
\item[\errcode{EWOULDBLOCK}] la funzione si sarebbe bloccata ma si è
richiesto \const{O\_NONBLOCK}.
\end{errlist}
- ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EMFILE},
+ ed inoltre \errval{EACCES}, \errval{EDQUOT}, \errval{EFAULT}, \errval{EMFILE},
\errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM}, \errval{ENOSPC},
\errval{EROFS}, nel loro significato generico.}
\end{funcproto}
da \param{flags}. Essa può essere invocata in due modi diversi, specificando
opzionalmente un terzo argomento \param{mode}. Qualora il file non esista e
venga creato, questo argomento consente di indicare quali permessi dovranno
-essergli assegnati. I valori possibili sono gli stessi già visti in
+essergli assegnati.\footnote{questo è possibile solo se si è usato in
+ \param{flags} uno fra \const{O\_CREATE} e \const{O\_TMPFILE}, in tutti gli
+ altri casi sarà ignorato.} I 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 tab.~\ref{tab:file_bit_perm}. Questi permessi sono
comunque filtrati dal valore della \textit{umask} (vedi
esso direttamente tramite il file descriptor, e quanto avviene al
\textit{pathname} con cui lo si è aperto sarà del tutto ininfluente.
-\itindbeg{file~status~flag}
+\itindbeg{file~status~flags}
Il comportamento della funzione, e le diverse modalità con cui può essere
aperto il file, vengono controllati dall'argomento \param{flags} il cui valore
deve essere indicato come maschera binaria in cui ciascun bit ha un
significato specifico. Alcuni di questi bit vanno anche a costituire i
-cosiddetti \textsl{flag di stato} del file (i cosiddetti \textit{file status
- flags}), che vengono mantenuti nel campo \var{f\_flags} della struttura
-\kstruct{file} che abbiamo riportato anche in fig.~\ref{fig:file_proc_file}).
+cosiddetti \textit{file status flags} (i \textsl{flag di stato} del file), che
+vengono mantenuti nel campo \var{f\_flags} della struttura \kstruct{file} che
+abbiamo riportato anche in fig.~\ref{fig:file_proc_file}).
Ciascun flag viene identificato da una apposita costante, ed il valore
di \param{flags} deve essere specificato come OR aritmetico di queste
system}''; pur essendo equivalenti alle definizioni classiche non è
comunque il caso di utilizzarle.}
-\itindend{file~status~flag}
+\itindend{file~status~flags}
Il secondo gruppo di flag è quello delle \textsl{modalità di
apertura},\footnote{la pagina di manuale di \func{open} parla di
\textbf{Flag} & \textbf{Significato} \\
\hline
\hline
- \constd{O\_CREAT} & Se il file non esiste verrà creato, con le regole
- di titolarità del file viste in
- sez.~\ref{sec:file_ownership_management}. Se si
- imposta questo flag l'argomento \param{mode} deve
- essere sempre specificato.\\
- \constd{O\_DIRECTORY}&Se \param{pathname} non è una directory la
- chiamata fallisce. Questo flag, introdotto con il
- kernel 2.1.126, è specifico di Linux e
- serve ad evitare dei possibili
- \itindex{Denial~of~Service~(DoS)}
- \textit{DoS}\footnotemark quando \func{opendir}
- viene chiamata su una fifo o su un dispositivo
- associato ad una unità a nastri. Non viene
- usato al di fuori dell'implementazione di
- \func{opendir}, ed è utilizzabile soltanto se si è
- definita la macro \macro{\_GNU\_SOURCE}.\\
- \constd{O\_EXCL} & Deve essere usato in congiunzione con
- \const{O\_CREAT} ed in tal caso impone che il file
- indicato da \param{pathname} non sia già esistente
- (altrimenti causa il fallimento della chiamata con
- un errore di \errcode{EEXIST}).\\
- \constd{O\_LARGEFILE}&Viene usato sui sistemi a 32 bit per richiedere
- l'apertura di file molto grandi, la cui
- dimensione non è rappresentabile con la versione a
- 32 bit del tipo \type{off\_t}, utilizzando
- l'interfaccia alternativa abilitata con la
- macro \macro{\_LARGEFILE64\_SOURCE}. Come
- illustrato in sez.~\ref{sec:intro_gcc_glibc_std} è
- sempre preferibile usare la conversione automatica
- delle funzioni che si attiva assegnando a $64$ la
- macro \macro{\_FILE\_OFFSET\_BITS}, e non usare mai
- questo flag.\\
- \constd{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}).\\
+ \constd{O\_CREAT} & Se il file non esiste verrà creato, con le regole
+ di titolarità del file viste in
+ sez.~\ref{sec:file_ownership_management}. Se si
+ imposta questo flag l'argomento \param{mode} deve
+ essere sempre specificato.\\
+ \constd{O\_DIRECTORY}& Se \param{pathname} non è una directory la
+ chiamata fallisce. Questo flag, introdotto con il
+ kernel 2.1.126, è specifico di Linux e
+ serve ad evitare dei possibili
+ \itindex{Denial~of~Service~(DoS)}
+ \textit{DoS}\footnotemark quando \func{opendir}
+ viene chiamata su una \textit{fifo} o su un
+ dispositivo associato ad una unità a nastri. Non
+ viene usato al di fuori dell'implementazione di
+ \func{opendir}, ed è utilizzabile soltanto se si è
+ definita la macro \macro{\_GNU\_SOURCE}.\\
+ \constd{O\_EXCL} & Deve essere usato in congiunzione con
+ \const{O\_CREAT} ed in tal caso impone che il file
+ indicato da \param{pathname} non sia già esistente
+ (altrimenti causa il fallimento della chiamata con
+ un errore di \errcode{EEXIST}).\\
+ \constd{O\_LARGEFILE}& Viene usato sui sistemi a 32 bit per richiedere
+ l'apertura di file molto grandi, la cui
+ dimensione non è rappresentabile con la versione a
+ 32 bit del tipo \type{off\_t}, utilizzando
+ l'interfaccia alternativa abilitata con la
+ macro \macro{\_LARGEFILE64\_SOURCE}. Come
+ illustrato in sez.~\ref{sec:intro_gcc_glibc_std} è
+ sempre preferibile usare la conversione automatica
+ delle funzioni che si attiva assegnando a $64$ la
+ macro \macro{\_FILE\_OFFSET\_BITS}, e non usare mai
+ questo flag.\\
+ \constd{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}).\\
\constd{O\_NOFOLLOW}& Se \param{pathname} è un collegamento simbolico
la chiamata fallisce. Questa è un'estensione BSD
aggiunta in Linux a partire dal kernel
2.1.126, ed utilizzabile soltanto se si è definita
- la macro \macro{\_GNU\_SOURCE}.\\
- \constd{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
- ne tronca la lunghezza a zero; con un terminale o
- una fifo viene ignorato, negli altri casi il
- comportamento non è specificato.\\
+ la macro \macro{\_GNU\_SOURCE}.\\
+ \const{O\_TMPFILE} & Consente di creare un file temporaneo anonimo, non
+ visibile con un pathname sul filesystem, ma
+ leggibile e scrivibile all'interno del processo.
+ Introdotto con il kernel 3.11, è specifico di
+ Linux.\\
+ \constd{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
+ ne tronca la lunghezza a zero; con un terminale o
+ una \textit{fifo} viene ignorato, negli altri casi
+ il comportamento non è specificato.\\
\hline
\end{tabular}
\caption{Le costanti che identificano le \textit{modalità di apertura} di
\label{tab:open_time_flag}
\end{table}
-
-% TODO: aggiungere O_TMPFILE per la creazione di file temporanei senza che
-% questi appaiano sul filesystem, introdotto con il 3.11, vedi:
-% https://lwn.net/Articles/556512/, http://kernelnewbies.org/Linux_3.11
-% https://lwn.net/Articles/558598/ http://lwn.net/Articles/619146/
-
\footnotetext{acronimo di \itindex{Denial~of~Service~(DoS)} \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
Si è riportato in tab.~\ref{tab:open_time_flag} l'elenco dei flag delle
\textsl{modalità di apertura}.\footnote{la \acr{glibc} definisce anche i due
- flag \constd{O\_SHLOCK}, che aprirebbe il file con uno \textit{shared lock} e
- \constd{O\_EXLOCK} che lo aprirebbe con un \textit{exclusive lock} (vedi
- sez.~\ref{sec:file_locking}, si tratta di opzioni specifiche di BSD, che non
+ flag \constd{O\_SHLOCK}, che aprirebbe il file con uno \textit{shared lock}
+ e \constd{O\_EXLOCK} che lo aprirebbe con un \textit{exclusive lock} (vedi
+ sez.~\ref{sec:file_locking}), si tratta di opzioni specifiche di BSD, che non
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 ``\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}).}
+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}, in tal caso
+infatti 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
-specificare l'argomento di \param{mode}, che altrimenti è ignorato. Si tenga
-presente che indipendentemente dai permessi che si possono assegnare, che in
-seguito potrebbero non consentire lettura o scrittura, quando il file viene
-aperto l'accesso viene garantito secondo quanto richiesto con i flag di
+indefinito, escluso il caso in cui viene usato con \const{O\_TMPFILE} su cui
+torneremo più avanti; un'altra eccezione è quello in cui lo si usa da solo su
+un file di dispositivo, in quel caso se questo è in uso (ad esempio se è
+relativo ad un filesystem che si è montato) si avrà un errore di
+\errval{EBUSY}, e pertanto può essere usato in questa modalità per rilevare lo
+stato del dispositivo.
+
+Nella creazione di un file con \const{O\_CREAT} occorre sempre specificare
+l'argomento di \param{mode}, che altrimenti è ignorato. Si tenga presente che
+indipendentemente dai permessi che si possono assegnare, che in seguito
+potrebbero non consentire lettura o scrittura, quando il file viene aperto
+l'accesso viene garantito secondo quanto richiesto con i flag di
tab.~\ref{tab:open_access_mode_flag}. Quando viene creato un nuovo file
\const{O\_CREAT} con tutti e tre i tempi del file di
tab.~\ref{tab:file_file_times} vengono impostati al tempo corrente. Se invece
si tronca il file con \const{O\_TRUNC} verranno impostati soltanto il
\textit{modification time} e lo \textit{status change time}.
+Il flag \label{open_o_tmpfile_flag} \constd{O\_TMPFILE}, introdotto con il
+kernel 3.11,\footnote{inizialmente solo su alcuni filesystem (i vari
+ \acr{extN}, \acr{Minix}, \acr{UDF}, \acr{shmem}) poi progressivamente esteso
+ ad altri (\acr{XFS} con il 3.15, \acr{Btrfs} e \acr{F2FS} con il 3.16,
+ \acr{ubifs} con il 4.9).} consente di aprire un file temporaneo senza che
+questo venga associato ad un nome e compaia nel filesystem. In questo caso la
+funzione restituirà un file descriptor da poter utilizzare per leggere e
+scrivere dati, ma il contenuto dell'argomento \param{path} verrà usato
+solamente per determinare, in base alla directory su cui si verrebbe a trovare
+il \textit{pathname} indicato, il filesystem all'interno del quale deve essere
+allocato l'\textit{inode} e lo spazio disco usato dal file
+descriptor. L'\textit{inode} resterà anonimo e l'unico riferimento esistente
+sarà quello contenuto nella \textit{file table} del processo che ha chiamato
+\func{open}.
+
+Lo scopo principale del flag è quello fornire una modalità atomica, semplice e
+sicura per applicare la tecnica della creazione di un file temporaneo seguita
+dalla sua immediata cancellazione con \func{unlink} per non lasciare rimasugli
+sul filesystem, di cui è parlato in sez.~\ref{sec:link_symlink_rename}.
+Inoltre, dato che il file non compare nel filesystem, si evitano alla radice
+tutti gli eventuali problemi di \textit{race condition} o \textit{symlink
+ attack} e non ci si deve neanche preoccupare di ottenere un opportuno nome
+univoco con l'uso delle funzioni di sez.~\ref{sec:file_temp_file}.
+
+Una volta aperto il file vi si potrà leggere o scrivere a seconda che siano
+utilizzati \const{O\_RDWR} o \const{O\_WRONLY}, mentre l'uso di
+\func{O\_RDONLY} non è consentito, non avendo molto senso ottenere un file
+descriptor su un file che nasce vuoto per cui non si potrà comunque leggere
+nulla. L'unico altro flag che può essere utilizzato insieme a
+\const{O\_TMPFILE} è \const{O\_EXCL}, che in questo caso assume però un
+significato diverso da quello ordinario, dato che in questo caso il file
+associato al file descriptor non esiste comunque.
+
+L'uso di \const{O\_EXCL} attiene infatti all'altro possibile impiego di
+\const{O\_TMPFILE} oltre a quello citato della creazione sicura di un file
+temporaneo come sostituto sicuro di \func{tmpfile}: la possibilità di creare
+un contenuto iniziale per un file ed impostarne permessi, proprietario e
+attributi estesi con \func{fchmod}, \func{fchown} e \func{fsetxattr}, senza
+possibilità di \textit{race condition} ed interferenze esterne, per poi far
+apparire il tutto sul filesystem in un secondo tempo utilizzando \func{linkat}
+sul file descriptor (torneremo su questo in sez.~\ref{sec:file_openat}) per
+dargli un nome. Questa operazione però non sarà possibile se si è usato
+\const{O\_EXCL}, che in questo caso viene ad assumere il significato di
+escludere la possibilità di far esistere il file anche in un secondo tempo.
+
+% NOTE: per O_TMPFILE vedi: http://kernelnewbies.org/Linux_3.11
+% https://lwn.net/Articles/558598/ http://lwn.net/Articles/619146/
+
+
\begin{table}[!htb]
\centering
\footnotesize
viene sempre mantenuta sulla sua coda, per cui
quanto si scrive viene sempre aggiunto al contenuto
precedente. Con NFS questa funzionalità non è
- supportata e viene emulata, per questo possono
+ supportata e viene emulata, per questo possono
verificarsi \textit{race condition} con una
sovrapposizione dei dati se più di un processo
scrive allo stesso tempo.\\
tutte le volte che il file è pronto per le
operazioni di lettura o scrittura. Questo flag si
può usare solo terminali, pseudo-terminali e socket
- e, a partire dal kernel 2.6, anche sulle fifo. Per
- un bug dell'implementazione non è opportuno usarlo
- in fase di apertura del file, deve
- invece essere attivato successivamente con
+ e, a partire dal kernel 2.6, anche sulle
+ \textit{fifo}. Per un bug dell'implementazione non
+ è opportuno usarlo in fase di apertura del file,
+ deve invece essere attivato successivamente con
\func{fcntl}.\\
\constd{O\_CLOEXEC}& Attiva la modalità di \textit{close-on-exec} (vedi
sez.~\ref{sec:proc_exec}) sul file. Il flag è
l'impostazione della suddetta modalità con
\func{fcntl} (vedi
sez.~\ref{sec:file_fcntl_ioctl}).\\
- \constd{O\_DIRECT} & Esegue l'I/O direttamente dalla memoria in
+ \const{O\_DIRECT} & Esegue l'I/O direttamente dalla memoria in
\textit{user space} in maniera sincrona, in modo da
scavalcare i meccanismi di bufferizzazione del
kernel. Introdotto con il kernel 2.4.10 ed
montaggio. Introdotto con il kernel 2.6.8 ed
utilizzabile soltanto se si è definita la
macro \macro{\_GNU\_SOURCE}.\\
- \constd{O\_NONBLOCK}&Apre il file in \textsl{modalità non bloccante} per
- le operazioni di I/O (vedi
- sez.~\ref{sec:file_noblocking}). Questo significa
- il fallimento delle successive operazioni di
- lettura o scrittura qualora il file non sia pronto
- per la loro esecuzione immediata, invece del
- blocco delle stesse in attesa di una successiva
- possibilità di esecuzione come avviene
- normalmente. Questa modalità ha senso solo per le
- fifo, vedi sez.~\ref{sec:ipc_named_pipe}), o quando
- si vuole aprire un file di dispositivo per eseguire
- una \func{ioctl} (vedi
- sez.~\ref{sec:file_fcntl_ioctl}).\\
+ \constd{O\_NONBLOCK}& Apre il file in \textsl{modalità non bloccante} per
+ le operazioni di I/O (vedi
+ sez.~\ref{sec:file_noblocking}). Questo significa
+ il fallimento delle successive operazioni di
+ lettura o scrittura qualora il file non sia pronto
+ per la loro esecuzione immediata, invece del
+ blocco delle stesse in attesa di una successiva
+ possibilità di esecuzione come avviene
+ normalmente. Questa modalità ha senso solo per le
+ \textit{fifo}, vedi sez.~\ref{sec:ipc_named_pipe}),
+ o quando si vuole aprire un file di dispositivo
+ per eseguire una \func{ioctl} (vedi
+ sez.~\ref{sec:file_fcntl_ioctl}).\\
\constd{O\_NDELAY} & In Linux è un sinonimo di \const{O\_NONBLOCK}, ma
origina da SVr4, dove però causava il ritorno da
una \func{read} con un valore nullo e non con un
come vedremo in sez.~\ref{sec:file_read} il ritorno
di un valore nullo da parte di \func{read} ha
il significato di una \textit{end-of-file}.\\
+ \const{O\_PATH} & Ottiene un file descriptor io cui uso è limitato
+ all'indicare una posizione sul filesystem o
+ eseguire operazioni che operano solo a livello del
+ file descriptor (e non di accesso al contenuto del
+ file). Introdotto con il kernel 2.6.39, è specifico
+ di Linux.\\
\constd{O\_SYNC} & Apre il file per l'input/output sincrono. Ogni
scrittura si bloccherà fino alla conferma
dell'arrivo di tutti i dati e di tutti i metadati
Il terzo gruppo è quello dei flag delle \textsl{modalità di operazione},
riportati in tab.~\ref{tab:open_operation_flag}, che permettono di specificare
varie caratteristiche del comportamento delle operazioni di I/O che verranno
-eseguite sul file. Tutti questi, tranne \const{O\_CLOEXEC}, che viene
-mantenuto per ogni singolo file descriptor, vengono salvati nel campo
-\var{f\_flags} della struttura \kstruct{file} insieme al valore della
-\textsl{modalità di accesso} andando far parte dei cosiddetti \textit{file
- status flags}. Il loro valore viene impostato alla chiamata di \func{open},
-ma possono venire riletti in un secondo tempo con \func{fcntl}, inoltre alcuni
-di essi possono anche essere modificati tramite questa funzione, con
-conseguente effetto sulle caratteristiche operative che controllano (torneremo
-sull'argomento in sez.~\ref{sec:file_fcntl_ioctl}).
-
-Il flag \const{O\_ASYNC} (che, per per compatibilità con BSD, si può indicare
+eseguite sul file o le modalità in cui lo si potrà utilizzare. Tutti questi,
+tranne \const{O\_CLOEXEC}, che viene mantenuto per ogni singolo file
+descriptor, vengono salvati nel campo \var{f\_flags} della struttura
+\kstruct{file} insieme al valore della \textsl{modalità di accesso}, andando
+far parte dei \textit{file status flags}. Il loro valore viene impostato alla
+chiamata di \func{open}, ma possono venire riletti in un secondo tempo con
+\func{fcntl}, inoltre alcuni di essi possono anche essere modificati tramite
+questa funzione, con conseguente effetto sulle caratteristiche operative che
+controllano (torneremo sull'argomento in sez.~\ref{sec:file_fcntl_ioctl}).
+
+Il flag \const{O\_ASYNC} (che, per compatibilità con BSD, si può indicare
anche con la costante \constd{FASYNC}) è definito come possibile valore per
\func{open}, ma per un bug dell'implementazione,\footnote{segnalato come
- ancora presente nella pagina di manuale almeno fino al Settembre 2011.} non
+ ancora presente nella pagina di manuale, almeno fino al novembre 2018.} non
solo non attiva il comportamento citato, ma se usato richiede di essere
esplicitamente disattivato prima di essere attivato in maniera effettiva con
l'uso di \func{fcntl}. Per questo motivo, non essendovi nessuna necessità
attivarlo in un secondo tempo con \func{fcntl} (vedi
sez.~\ref{sec:file_fcntl_ioctl}).
-Il flag \const{O\_DIRECT} non è previsto da nessuno standard, anche se è
+Il flag \constd{O\_DIRECT} non è previsto da nessuno standard, anche se è
presente in alcuni kernel unix-like.\footnote{il flag è stato introdotto dalla
SGI in IRIX, ma è presente senza limiti di allineamento dei buffer anche in
FreeBSD.} Per i kernel della serie 2.4 si deve garantire che i buffer in
sulla scrittura sincrona dei metadati associati alla scrittura dei dati del
file.\footnote{la situazione si complica ulteriormente per NFS, in cui l'uso
del flag disabilita la bufferizzazione solo dal lato del client, e può
- causare problemi di prestazioni.} Per questo in genere è opportuno se si usa
+ causare problemi di prestazioni.} Per questo in genere se si usa
\const{O\_DIRECT} è opportuno richiedere anche \const{O\_SYNC}.
Si tenga presente infine che la implementazione di \const{O\_SYNC} di Linux
% NOTE: per le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
% nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
+Il flag \constd{O\_PATH},\label{open_o_path_flag} introdotto con il kernel
+2.6.39, viene usato per limitare l'uso del file descriptor restituito da
+\func{open} o all'identificazione di una posizione sul filesystem (ad uso
+delle \textit{at-functions} che tratteremo in sez.~\ref{sec:file_openat}) o
+alle operazioni che riguardano il file descriptor in quanto tale, senza
+consentire operazioni sul file; in sostanza se si apre un file con
+\const{O\_PATH} si potrà soltanto:
+\begin{itemize*}
+\item usare il file descriptor come indicatore della directory di partenza con
+ una delle \textit{at-functions} (vedi sez.~\ref{sec:file_openat});
+\item cambiare directory di lavoro con \func{fchdir} se il file descriptor fa
+ riferimento a una directory (dal kernel 3.5);
+\item usare le funzioni che duplicano il file descriptor (vedi
+ sez.~\ref{sec:file_dup});
+\item passare il file descriptor ad un altro processo usando un socket
+ \const{PF\_UNIX} (vedi sez.~\ref{sec:unix_socket})
+\item ottenere le informazioni relative al file con \func{fstat} (dal kernel
+ 3.6) o al filesystem con \func{fstatfs} (dal kernel 3.12);
+\item ottenere il valore dei \textit{file descriptor flags} (fra cui comparirà
+ anche lo stesso \const{O\_PATH}) o impostare o leggere i \textit{file status
+ flags} con \func{fcntl} (rispettivamente con le operazioni
+ \const{F\_GETFL}, \const{F\_SETFD} e \const{F\_GETFD}, vedi
+ sez.~\ref{sec:file_fcntl_ioctl}).
+\item chiudere il file con \func{close}.
+\end{itemize*}
+
+In realtà usando \const{O\_PATH} il file non viene effettivamente aperto, per
+cui ogni tentativo di usare il file descriptor così ottenuto con funzioni che
+operano effettivamente sul file (come ad esempio \func{read}, \func{write},
+\func{fchown}, \func{fchmod}, \func{ioctl}, ecc.) fallirà con un errore di
+\errval{EBADF}, come se questo non fosse un file descriptor valido. Per questo
+motivo usando questo flag non è necessario avere nessun permesso per aprire un
+file, neanche quello di lettura (ma occorre ovviamente avere il permesso di
+esecuzione per le directory sovrastanti).
+
+Questo consente di usare il file descriptor con funzioni che non richiedono
+permessi sul file, come \func{fstat}, laddove un'apertura con
+\const{O\_RDONLY} sarebbe fallita. I permessi verranno eventualmente
+controllati, se necessario, nelle operazioni seguenti, ad esempio per usare
+\func{fchdir} con il file descriptor (se questo fa riferimento ad una
+directory) occorrerà avere il permesso di esecuzione.
+
+Se si usa \const{O\_PATH} tutti gli altri flag eccettuati \const{O\_CLOEXEC},
+\const{O\_DIRECTORY} e \const{O\_NOFOLLOW} verranno ignorati. I primi due
+mantengono il loro significato usuale, mentre \const{O\_NOFOLLOW} fa si che se
+il file indicato è un un link simbolico venga aperto quest'ultimo (cambiando
+quindi il comportamento ordinario che prova il fallimento della chiamata),
+così da poter usare il file descriptor ottenuto per le funzioni
+\func{fchownat}, \func{fstatat}, \func{linkat} e \func{readlinkat} che ne
+supportano l'uso come come primo argomento (torneremo su questo in
+sez.~\ref{sec:file_openat}).
+
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
questo motivo per creare un nuovo file c'era una \textit{system call}
automaticamente chiusi, molti programmi sfruttano questa caratteristica e non
usano esplicitamente \func{close}. In genere comunque chiudere un file senza
controllare lo stato di uscita di \func{close} un è errore; molti filesystem
-infatti implementano la tecnica del cosiddetto \textit{write-behind}, per cui
-una \func{write} può avere successo anche se i dati non sono stati
-effettivamente scritti su disco. In questo caso un eventuale errore di I/O
-avvenuto in un secondo tempo potrebbe sfuggire, mentre verrebbe riportato alla
-chiusura esplicita del file. Per questo motivo non effettuare il controllo può
-portare ad una perdita di dati inavvertita.\footnote{in Linux questo
- comportamento è stato osservato con NFS e le quote su disco.}
+infatti implementano la tecnica del cosiddetto \itindex{write-behind}
+\textit{write-behind}, per cui una \func{write} può avere successo anche se i
+dati non sono stati effettivamente scritti su disco. In questo caso un
+eventuale errore di I/O avvenuto in un secondo tempo potrebbe sfuggire, mentre
+verrebbe riportato alla chiusura esplicita del file. Per questo motivo non
+effettuare il controllo può portare ad una perdita di dati
+inavvertita.\footnote{in Linux questo comportamento è stato osservato con NFS
+ e le quote su disco.}
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 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 questo deriva
-l'abitudine di alcuni sistemisti di ripetere tre volte il comando omonimo
-prima di eseguire lo shutdown di una macchina.
-
+\func{sync} (vedi sez.~\ref{sec:file_sync}) effettua esplicitamente lo scarico
+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 questo deriva l'abitudine di
+alcuni sistemisti di ripetere tre volte il comando omonimo prima di eseguire
+lo shutdown di una macchina.
+
+Si tenga comunque presente che ripetere la chiusura in caso di fallimento non
+è opportuno, una volta chiamata \func{close} il file descriptor viene comunque
+rilasciato, indipendentemente dalla presenza di errori, e se la riesecuzione
+non comporta teoricamente problemi (se non la sua inutilità) se fatta
+all'interno di un processo singolo, nel caso si usino i \textit{thread} si
+potrebbe chiudere un file descriptor aperto nel contempo da un altro
+\textit{thread}.
\subsection{La gestione della posizione nel file}
\label{sec:file_lseek}
Infine si tenga presente che, come accennato in sez.~\ref{sec:file_file_size},
con \func{lseek} è possibile impostare una posizione anche oltre la corrente
fine del file. In tal caso alla successiva scrittura il file sarà esteso a
-partire da detta posizione, con la creazione di quello che viene chiamato
+partire da detta posizione, con la creazione di quello che viene chiamato un
``\textsl{buco}'' (in gergo \textit{hole}) nel file. Il nome deriva dal fatto
che nonostante la dimensione del file sia cresciuta in seguito alla scrittura
-effettuata, lo spazio vuoto fra la precedente fine del file ed la nuova parte
-scritta dopo lo spostamento non corrisponde ad una allocazione effettiva di
+effettuata, lo spazio vuoto fra la precedente fine del file e la nuova parte,
+scritta dopo lo spostamento, non corrisponde ad una allocazione effettiva di
spazio su disco, che sarebbe inutile dato che quella zona è effettivamente
vuota.
Questa è una delle caratteristiche specifiche della gestione dei file di un
-sistema unix-like e si dice che il file in questione è uno \textit{sparse
- file}. In sostanza, se si ricorda la struttura di un filesystem illustrata
-in fig.~\ref{fig:file_filesys_detail}, quello che accade è che
-nell'\textit{inode} del file viene segnata l'allocazione di un blocco di dati
-a partire dalla nuova posizione, ma non viene allocato nulla per le posizioni
-intermedie; in caso di lettura sequenziale del contenuto del file il kernel si
-accorgerà della presenza del buco, e restituirà degli zeri come contenuto di
-quella parte del file.
+sistema unix-like e quando si ha questa situazione si dice che il file in
+questione è uno \textit{sparse file}. In sostanza, se si ricorda la struttura
+di un filesystem illustrata in fig.~\ref{fig:file_filesys_detail}, quello che
+accade è che nell'\textit{inode} del file viene segnata l'allocazione di un
+blocco di dati a partire dalla nuova posizione, ma non viene allocato nulla
+per le posizioni intermedie. In caso di lettura sequenziale del contenuto del
+file il kernel si accorgerà della presenza del buco, e restituirà degli zeri
+come contenuto di quella parte del file.
Questa funzionalità comporta una delle caratteristiche della gestione dei file
su Unix che spesso genera più confusione in chi non la conosce, per cui
\cmd{du}, che calcola lo spazio disco occupato in base al numero dei blocchi
effettivamente allocati per il file.
-Questo avviene proprio perché in un sistema unix-like la dimensione di un file
-è una caratteristica del tutto indipendente dalla quantità di spazio disco
-effettivamente allocato, e viene registrata sull'\textit{inode} come le altre
-proprietà del file. La dimensione viene aggiornata automaticamente quando si
-estende un file scrivendoci, e viene riportata dal campo \var{st\_size} di una
-struttura \struct{stat} quando si effettua la chiamata ad una delle funzioni
-\texttt{*stat} viste in sez.~\ref{sec:file_stat}.
-
-Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
-la dimensione di un file sarà più o meno corrispondente alla quantità di
-spazio disco da esso occupato, ma esistono dei casi, come questo in cui ci si
-sposta in una posizione oltre la fine corrente del file, o come quello
-accennato in in sez.~\ref{sec:file_file_size} in cui si estende la dimensione
-di un file con una \func{truncate}, in cui in sostanza si modifica il valore
-della dimensione di \var{st\_size} senza allocare spazio su disco. Questo
-consente di creare inizialmente file di dimensioni anche molto grandi, senza
-dover occupare da subito dello spazio disco che in realtà sarebbe
-inutilizzato.
+Tutto ciò avviene proprio perché in un sistema unix-like la dimensione di un
+file è una caratteristica del tutto indipendente dalla quantità di spazio
+disco effettivamente allocato, e viene registrata sull'\textit{inode} come le
+altre proprietà del file. La dimensione viene aggiornata automaticamente
+quando si estende un file scrivendoci, e viene riportata dal campo
+\var{st\_size} di una struttura \struct{stat} quando si effettua la chiamata
+ad una delle funzioni \texttt{*stat} viste in sez.~\ref{sec:file_stat}.
+
+Questo comporta che la dimensione di un file, fintanto che lo si è scritto
+sequenzialmente, sarà corrispondente alla quantità di spazio disco da esso
+occupato, ma possono esistere dei casi, come questo in cui ci si sposta in una
+posizione oltre la fine corrente del file, o come quello accennato in
+sez.~\ref{sec:file_file_size} in cui si estende la dimensione di un file con
+una \func{truncate}, in cui si modifica soltanto il valore della dimensione di
+\var{st\_size} senza allocare spazio su disco. Così è possibile creare
+inizialmente file di dimensioni anche molto grandi, senza dover occupare da
+subito dello spazio disco che in realtà sarebbe inutilizzato.
\itindend{sparse~file}
di \param{offset}.
Inoltre la decisione di come riportare (o di non riportare) la presenza di un
-buco in un file è lasciata all'implementazione del
-filesystem, dato che esistono vari motivi per cui una sezione di un file può
-non contenere dati ed essere riportata come tale (ad esempio può essere stata
-preallocata con \func{fallocate}, vedi sez.~\ref{sec:file_fadvise}) oltre a
-quelle classiche appena esposte. Questo significa che l'uso di questi nuovi
+buco in un file è lasciata all'implementazione del filesystem, dato che oltre
+a quelle classiche appena esposte esistono vari motivi per cui una sezione di
+un file può non contenere dati ed essere riportata come tale (ad esempio può
+essere stata preallocata con \func{fallocate}, vedi
+sez.~\ref{sec:file_fadvise}). Questo significa che l'uso di questi nuovi
valori non garantisce la mappatura della effettiva allocazione dello spazio
disco di un file, per il quale esiste una specifica operazione di controllo
(vedi sez.~\ref{sec:file_fcntl_ioctl}).
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 \func{read} è una delle \textit{system call} fondamentali,
esistenti fin dagli albori di Unix, ma nella seconda versione delle
\textit{Single Unix Specification}\footnote{questa funzione, e l'analoga
- \func{pwrite} sono state aggiunte nel kernel 2.1.60, il supporto nelle
+ \func{pwrite} sono state aggiunte nel kernel 2.1.60, il supporto nella
\acr{glibc}, compresa l'emulazione per i vecchi kernel che non hanno la
\textit{system call}, è stato aggiunto con la versione 2.1, in versioni
precedenti sia del kernel che delle librerie la funzione non è disponibile.}
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 letti 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}
\begin{errlist}
\item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
modalità \const{O\_NONBLOCK}.
+ \item[\errcode{EDESTADDRREQ}] si è eseguita una scrittura su un socket di
+ tipo \textit{datagram} (vedi sez.~\ref{sec:sock_type}) senza aver prima
+ connesso il corrispondente con \func{connect} (vedi
+ sez.~\ref{sec:UDP_sendto_recvfrom}).
\item[\errcode{EFBIG}] si è cercato di scrivere oltre la dimensione massima
consentita dal filesystem o il limite per le dimensioni dei file del
processo o su una posizione oltre il massimo consentito.
potuto scrivere qualsiasi dato.
\item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
la scrittura o si è usato \const{O\_DIRECT} ed il buffer non è allineato.
+ \item[\errcode{EPERM}] la scrittura è proibita da un \textit{file seal}
+ (vedi sez.~\ref{sec:file_fcntl_ioctl}).
\item[\errcode{EPIPE}] \param{fd} è connesso ad una \textit{pipe} il cui
altro capo è chiuso in lettura; in questo caso viene anche generato il
segnale \signal{SIGPIPE}, se questo viene gestito (o bloccato o ignorato)
la funzione ritorna questo errore.
\end{errlist}
- ed inoltre \errval{EBADF}, \errval{EFAULT}, \errval{EIO}, \errval{EISDIR},
- \errval{ENOSPC} nel loro significato generico.}
+ ed inoltre \errval{EBADF}, \errval{EDQUOT}, \errval{EFAULT}, \errval{EIO},
+ \errval{EISDIR}, \errval{ENOSPC} nel loro significato generico.}
\end{funcproto}
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}
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 cap.~\ref{cha:file_advanced}).
+dell'argomento sarà comunque affrontato nel cap.~\ref{cha:file_advanced}).
\subsection{La gestione dell'accesso concorrente ai files}
\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
figlio riceve una copia dello spazio di indirizzi del padre, riceverà anche
una copia di \kstruct{file\_struct} e della relativa tabella dei file aperti.
-Questo significa che il figlio avrà gli stessi file aperti del padre, in
+Questo significa che il figlio avrà gli stessi file aperti del padre in
quanto la sua \kstruct{file\_struct}, pur essendo allocata in maniera
indipendente, contiene gli stessi valori di quella del padre e quindi i suoi
file descriptor faranno riferimento alla stessa voce nella \textit{file
automatica della posizione sul file fra padre e figlio che occorre tenere
presente.
+\itindbeg{close-on-exec}
+
Si noti inoltre che in questo caso anche i flag di stato del file, essendo
mantenuti nella struttura \kstruct{file} della \textit{file table}, vengono
condivisi, per cui una modifica degli stessi con \func{fcntl} (vedi
sez.~\ref{sec:file_fcntl_ioctl}) si applicherebbe a tutti processi che
condividono la voce nella \textit{file table}. Ai file però sono associati
-anche altri flag, dei quali l'unico usato al momento è \constd{FD\_CLOEXEC},
-detti \itindex{file~descriptor~flags} \textit{file descriptor flags}; questi
-invece sono mantenuti in \kstruct{file\_struct}, e perciò sono locali per
-ciascun processo e non vengono modificati dalle azioni degli altri anche in
-caso di condivisione della stessa voce della \textit{file table}.
+anche altri flag detti \itindex{file~descriptor~flags} \textit{file descriptor
+ flags}. Questi invece sono mantenuti in \kstruct{file\_struct}, e perciò
+sono locali per ciascun processo e non vengono modificati dalle azioni degli
+altri anche in caso di condivisione della stessa voce della \textit{file
+ table}; l'unico usato al momento è quello di \textit{close-on-exec} che
+indica che il file descriptor deve essere chiuso in una \func{exec} (vedi
+sez.~\ref{sec:proc_exec}).
+
+\itindend{close-on-exec}
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}
suo \textit{file descriptor flag} indipendente. A questo proposito deve essere
tenuto presente che nel caso in cui si usi \func{dup} per duplicare un file
descriptor, se questo ha il flag di \textit{close-on-exec} attivo (vedi
-sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl_ioctl}), questo verrà
+sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_shared_access}), questo verrà
cancellato nel file descriptor restituito come copia.
L'uso principale di questa funzione è nella shell per la redirezione dei file
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 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
-\func{write}.
+in maniera asincrona per ottimizzarle, ad esempio accorpando gli accessi alla
+stessa zona del disco in un secondo tempo rispetto al momento della esecuzione
+della \func{write}.
-Per questo motivo quando è necessaria una sincronizzazione dei dati il sistema
-mette a disposizione delle funzioni che provvedono a forzare lo scarico dei
-dati dai buffer del kernel. La prima di queste funzioni di sistema è
-\funcd{sync}, il cui prototipo è:\footnote{questo è il prototipo usato a
- partire dalla \acr{glibc} 2.2.2 seguendo gli standard, in precedenza la
- funzione era definita come \code{int sync(void)} e ritornava sempre $0$.}
+Per questo motivo quando è necessaria una sincronizzazione immediata dei dati
+il sistema mette a disposizione delle funzioni che provvedono a forzare lo
+scarico dei dati dai buffer del kernel. La prima di queste funzioni di
+sistema è \funcd{sync}, il cui prototipo è:\footnote{questo è il prototipo
+ usato a partire dalla \acr{glibc} 2.2.2 seguendo gli standard, in precedenza
+ la funzione era definita come \code{int sync(void)} e ritornava sempre $0$.}
\begin{funcproto}{
\fhead{unistd.h}
\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
-\sysctlfile{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
come i tempi del file. Se lo scopo dell'operazione, come avviene spesso per i
database, è assicurarsi che i dati raggiungano il disco e siano rileggibili
immediatamente in maniera corretta, è sufficiente l'uso di \func{fdatasync}
-che non comporta anche l'esecuzione di operazioni non necessarie all'integrità
-dei dati, come l'aggiornamento dei tempi di ultima modifica ed ultimo accesso.
+che evita le scritture non necessarie per avere l'integrità dei dati, come
+l'aggiornamento dei tempi di ultima modifica ed ultimo accesso.
Si tenga presente che l'uso di queste funzioni non comporta la
sincronizzazione della directory che contiene il file e la scrittura della
con l'opzione \cmd{sync}, il kernel provvede anche alla sincronizzazione
automatica delle voci delle directory.}
-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
-interesserebbe che questo avvenga soltanto su quello dei file su cui si sta
-lavorando, se i dati in attesa sono molti questo può causare seri problemi di
-prestazioni.
+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} può causare, quando ci sono più filesystem montati,
+problemi di prestazioni dovuti al fatto che effettua la sincronizzazione dei
+dati su tutti i filesystem, anche quando sarebbe sufficiente eseguirla
+soltanto su quello dei file su cui si sta lavorando; quando i dati in attesa
+sono molti questo può causare una alta attività di I/O ed i relativi problemi
+di prestazioni.
Per questo motivo è stata introdotta una nuova funzione di sistema,
\funcd{syncfs},\footnote{la funzione è stata introdotta a partire dal kernel
\end{funcproto}
La funzione richiede che si specifichi nell'argomento \param{fd} un file
-descriptor su cui si sta operando, e lo scarico dei dati sarà limitato al
-filesystem su cui il file ad esso corrispondente si trova.
+descriptor su cui si sta operando, e la registrazione immediata dei dati sarà
+limitata al filesystem su cui il file ad esso corrispondente si trova.
+
-\subsection{Le \textit{at-functions}: \func{openat} e affini}
+\subsection{Le \textit{at-functions}: \func{openat} e le altre}
\label{sec:file_openat}
\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}).
-
-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.
+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})
+cambiando una delle directory sovrastanti il file fra un controllo e la
+successiva apertura.
+
+Inoltre, come già accennato, la directory di lavoro corrente è una proprietà
+associata al singolo processo; questo significa che quando si lavora con i
+\textit{thread} questa è la stessa per tutti, per cui se la si cambia
+all'interno di un \textit{thread} il cambiamento varrà anche per tutti gli
+altri. Non esiste quindi con le funzioni classiche un modo semplice per far sì
+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
+funzioni di sistema, chiamate genericamente ``\textit{at-functions}'' in
+quanto usualmente 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
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}.}
+Essendo accomunate dalla stessa interfaccia le tratteremo insieme in questa
+sezione pur non essendo strettamente attinenti l'I/O su file.
+
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
+ad essere incluse in una recente revisione dello standard POSIX.1 (la
+POSIX.1-2008). Con la \acr{glibc} per l'accesso a queste funzioni è necessario
+definire la macro \macro{\_ATFILE\_SOURCE} (comunque attiva di default).
+
+L'uso di queste funzioni richiede una apertura preliminare della directory che
+si intende usare come base per la risoluzione dei \textit{pathname} relativi
+(ad esempio usando \func{open} con il flag \const{O\_PATH} visto in
+sez.~\ref{sec:file_open_close}) per ottenere un file descriptor che dovrà
+essere passato alle stesse. Tutte queste funzioni infatti prevedono la
+presenza un apposito argomento, in genere il primo che negli esempi seguenti
+chiameremo sempre \param{dirfd}, per indicare la directory di partenza.
+
+In questo modo, una volta aperta la directory di partenza, si potranno
+effettuare controlli ed aperture solo con \textit{pathname} relativi alla
+stessa, e tutte le \textit{race condition} dovute al possibile cambiamento di
+uno dei componenti posti al di sopra della stessa cesseranno di esistere.
+Inoltre, pur restando la directory di lavoro una proprietà comune del
+processo, si potranno usare queste funzioni quando si lavora con i
+\textit{thread} per eseguire la risoluzione dei \textit{pathname} relativi ed
+avere una directory di partenza diversa in ciascuno di essi.
+
+Questo metodo consente inoltre 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. Infine poter identificare una directory di partenza
+tramite il suo file descriptor consente di avere un riferimento stabile alla
+stessa anche qualora venisse rinominata, e tiene occupato il filesystem dove
+si trova come per la directory di lavoro di un processo.
+
+La sintassi generica di queste nuove funzioni prevede 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 \param{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
+se per \param{dirfd} si usa il valore speciale \constd{AT\_FDCWD} la
risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
-processo. Si tenga presente però che questa, come le altre costanti
-\texttt{AT\_*}, è definita in \headfile{fcntl.h}, pertanto se la si vuole
-usare occorrerà includere comunque questo file, anche per le funzioni che non
-sono definite in esso.
+processo. Questa, come le altre costanti \texttt{AT\_*}, è definita in
+\headfile{fcntl.h}, per cui per usarla occorrerà includere comunque questo
+file, anche per le funzioni che non sono definite in esso.
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
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
-\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
\textbf{Funzione} &\textbf{Flags} &\textbf{Corrispondente} \\
\hline
\hline
+ \func{execveat} &$\bullet$&\func{execve} \\
\func{faccessat} &$\bullet$&\func{access} \\
- \funcm{fchmodat} &$\bullet$&\func{chmod} \\
+ \func{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} \\
+ \func{fstatat} &$\bullet$&\func{stat},\func{lstat} \\
+ \funcm{futimesat}& -- & obsoleta \\
+ \func{linkat} &$\bullet$&\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} \\
+ \func{renameat} & -- &\func{rename} \\
+ \func{renameat2}\footnotemark& -- &\func{rename} \\
+ \funcm{scandirat}& -- &\func{scandir} \\
+ \func{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
\label{tab:file_atfunc_corr}
\end{table}
-\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
- utilizzabile solo a partire dal kernel 2.6.18.}
+\footnotetext{anche se la funzione ha un argomento \param{flags} questo
+ attiene a funzionalità specifiche della stessa e non all'uso generico fatto
+ nelle altre \textit{at-functions}, pertanto lo si è indicato come assente.}
In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte
con questa nuova interfaccia, con a fianco la corrispondente funzione
-classica. La gran parte di queste seguono la convenzione appena vista per
-\func{openat}, in cui agli argomenti della corrispondente funzione classica
-viene anteposto l'argomento \param{dirfd}, ed hanno per il resto un
-comportamento identico e non staremo pertanto a trattarle una per una. Per una
-parte di queste, indicate dal contenuto della omonima colonna di
+classica. Tutte seguono la convenzione appena vista per \func{openat}, in cui
+agli argomenti della funzione classica viene anteposto l'argomento
+\param{dirfd}. Per alcune, indicate dal contenuto della omonima colonna di
tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è prevista
-anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
-
+anche l'aggiunta di un argomento finale, \param{flags}, che è stato introdotto
+per fornire un meccanismo con cui modificarne il comportamento.
+
+Per tutte quelle che non hanno un argomento aggiuntivo il comportamento è
+identico alla corrispondente funzione ordinaria, pertanto non le tratteremo
+esplicitamente, vale per loro quanto detto con \func{openat} per l'uso del
+nuovo argomento \param{dirfd}. Tratteremo invece esplicitamente tutte quelle
+per cui l'argomento è presente, in quanto il loro comportamento viene
+modificato a seconda del valore assegnato a \param{flags}; questo deve essere
+passato come maschera binaria con una opportuna combinazione delle costanti
+elencate in tab.~\ref{tab:at-functions_constant_values}, in quanto sono
+possibili diversi valori a seconda della funzione usata.
-% TODO manca prototipo di linkat, verificare se metterlo o metter menzione
-% altre modifiche al riguardo nel 3.11 (AT_EMPTY_PATH?) vedi
-% http://lwn.net/Articles/562488/
-% TODO manca prototipo di utimensat, verificare se metterlo o metter menzione
-% TODO manca prototipo di renameat2, introdotta nel 3.15, vedi
-% http://lwn.net/Articles/569134/
-% TODO manca prototipo di execveat, introdotta nel 3.19, vedi
-% https://lwn.net/Articles/626150/ cerca anche fexecve
-
-
-Per tutte le funzioni che lo prevedono, a parte \func{unlinkat} e
-\funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
-un meccanismo con cui modificarne il comportamento nel caso si stia operando
-su un collegamento simbolico, così da poter scegliere se far agire la funzione
-direttamente sullo stesso o sul file da esso referenziato. Dato che in certi
-casi esso può fornire ulteriori indicazioni per modificare il comportamento
-delle funzioni, \param{flags} deve comunque essere passato come maschera
-binaria, ed impostato usando i valori delle appropriate costanti
-\texttt{AT\_*}, definite in \headfile{fcntl.h}.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{AT\_EMPTY\_PATH} & Usato per operare direttamente (specificando
+ una stringa vuota per il \texttt{pathname})
+ sul file descriptor \param{dirfd} che in
+ questo caso può essere un file qualunque.\\
+ \constd{AT\_SYMLINK\_NOFOLLOW}& Se impostato la funzione non esegue la
+ dereferenziazione dei collegamenti
+ simbolici.\\
+ \hline
+ \constd{AT\_EACCES} & Usato solo da \func{faccessat}, richiede che
+ il controllo dei permessi sia fatto usando
+ l'\ids{UID} effettivo invece di quello
+ reale.\\
+ \constd{AT\_NO\_AUTOMOUNT} & Usato solo da \func{fstatat} e \func{statx},
+ evita il montaggio automatico qualora
+ \param{pathname} faccia riferimento ad una
+ directory marcata per
+ l'\textit{automount}\footnotemark
+ (dal kernel 2.6.38).\\
+ \constd{AT\_REMOVEDIR} & Usato solo da \func{unlinkat}, richiede che
+ la funzione si comporti come \func{rmdir}
+ invece che come \func{unlink}.\\
+ \constd{AT\_SYMLINK\_FOLLOW}& Usato solo da \func{linkat}, se impostato la
+ funzione esegue la dereferenziazione dei
+ collegamenti simbolici.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti utilizzate per i bit dell'argomento aggiuntivo
+ \param{flags} delle \textit{at-functions}, definite in
+ \headfile{fcntl.h}.}
+ \label{tab:at-functions_constant_values}
+\end{table}
-Come esempio di questo secondo tipo di funzioni possiamo considerare
-\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
-che \func{lchown}; il suo prototipo è:
+\footnotetext{l'\textit{automount} \itindex{automount} è una funzionalità
+ fornita dal kernel che consente di montare automaticamente una directory
+ quando si accede ad un \textit{pathname} al di sotto di essa, per i
+ dettagli, di natura prevalentemente sistemistica, si può consultare
+ sez.~5.1.6 di \cite{AGL}.}
+
+Si tenga presente che non tutte le funzioni che prevedono l'argomento
+aggiuntivo sono \textit{system call}, ad esempio \func{faccessat} e
+\func{fchmodat} sono realizzate con dei \textit{wrapper} nella \acr{glibc} per
+aderenza allo standard POSIX.1-2008, dato che la \textit{system call}
+sottostante non prevede l'argomento \param{flags}.
+
+In tab.~\ref{tab:at-functions_constant_values} si sono elencati i valori
+utilizzabili per i flag (tranne quelli specifici di \func{statx} su cui
+torneremo più avanti), mantenendo nella prima parte quelli comuni usati da più
+funzioni. Il primo di questi è \const{AT\_SYMLINK\_NOFOLLOW}, che viene usato
+da tutte le funzioni tranne \func{linkat} e \func{unlinkat}, e che consente di
+scegliere, quando si sta operando su un collegamento simbolico, se far agire
+la funzione direttamente sullo stesso o sul file da esso referenziato. Si
+tenga presente però che per \funcm{fchmodat} questo, che è l'unico flag
+consentito e previsto dallo standard, non è attualmente implementato (anche
+perché non avrebbe molto senso cambiare i permessi di un link simbolico) e
+pertanto l'uso della funzione è analogo a quello delle altre funzioni che non
+hanno l'argomento \param{flags} (e non la tratteremo esplicitamente).
+
+L'altro flag comune è \const{AT\_EMPTY\_PATH}, utilizzabile a partire dal
+kernel 2.6.39, che consente di usare per \param{dirfd} un file descriptor
+associato ad un file qualunque e non necessariamente ad una directory; in
+particolare si può usare un file descriptor ottenuto aprendo un file con il
+flag \param{O\_PATH} (vedi quanto illustrato a
+pag.~\pageref{open_o_path_flag}). Quando si usa questo flag \param{pathname}
+deve essere vuoto, da cui il nome della costante, ed in tal caso la funzione
+agirà direttamente sul file associato al file descriptor \param{dirfd}.
+
+Una prima funzione di sistema che utilizza l'argomento \param{flag} è
+\funcd{fchownat}, che può essere usata per sostituire sia \func{chown} che
+\func{lchown}; il suo prototipo è:
\begin{funcproto}{
-\fhead{unistd.h}
\fhead{fcntl.h}
+\fhead{unistd.h}
\fdecl{int fchownat(int dirfd, const char *pathname, uid\_t owner, gid\_t
group, int flags)}
\fdesc{Modifica il proprietario di un file.}
}
\end{funcproto}
-In questo caso il valore di \param{flags} stabilisce il comportamento della
-funzione quando la si applica ad un collegamento simbolico, e l'unico valore
-utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}, che se impostato indica alla
-funzione di non eseguire la dereferenziazione di un eventuale collegamento
-simbolico, facendo comportare \func{fchownat} come \func{lchown} invece che
-come \func{chown}.
+In questo caso, oltre a quanto già detto per \func{openat} riguardo all'uso di
+\param{dirfd}, se si è impostato \const{AT\_SYMLINK\_NOFOLLOW} in
+\param{flags}, si indica alla funzione di non eseguire la dereferenziazione di
+un eventuale collegamento simbolico, facendo comportare \func{fchownat} come
+\func{lchown} invece che come \func{chown}. La funzione supporta anche l'uso
+di \const{AT\_EMPTY\_PATH}, con il significato illustrato in precedenza e non
+ha flag specifici.
-Come accennato fra tutte quelle marcate in tab.~\ref{tab:file_atfunc_corr}
-solo due funzioni possono usare l'argomento \param{flags} per indicare altro
-rispetto alla possibilità di seguire o meno un collegamento simbolico, la
-prima di queste è \funcd{faccessat}, ed il suo prototipo è:
+Una seconda funzione di sistema che utilizza l'argomento \param{flags}, in
+questo caso anche per modificare il suo comportamento, è \funcd{faccessat}, ed
+il suo prototipo è:
\begin{funcproto}{
+\fhead{fcntl.h}
\fhead{unistd.h}
\fdecl{int faccessat(int dirfd, const char *path, int mode, int flags)}
\fdesc{Controlla i permessi di accesso.}
}
\end{funcproto}
-La funzione esegue il controllo di accesso ad un file, ma
-l'argomento \param{flags} consente di modificarne il comportamento rispetto a
-quello ordinario di \func{access}. In questo caso esso può essere specificato
-come maschera binaria di due valori: il solito \const{AT\_SYMLINK\_NOFOLLOW},
-con il significato già spiegato, e \const{AT\_EACCES} per indicare alla
-funzione di eseguire il controllo dei permessi usando l'\ids{UID} effettivo
-invece di quello reale (il comportamento di default, che riprende quello di
-\func{access}).
-
+La funzione esegue il controllo di accesso ad un file, e \param{flags}
+consente di modificarne il comportamento rispetto a quello ordinario di
+\func{access} (cui è analoga e con cui condivide i problemi di sicurezza
+visti in sez.~\ref{sec:file_stat}) usando il valore \const{AT\_EACCES} per
+indicare alla funzione di eseguire il controllo dei permessi con l'\ids{UID}
+\textsl{effettivo} invece di quello \textsl{reale}. L'unico altro valore
+consentito è \const{AT\_SYMLINK\_NOFOLLOW}, con il significato già spiegato.
-La seconda eccezione è \funcd{unlinkat}, in questo caso
-l'argomento \param{flags} viene utilizzato perché tramite esso si può indicare
-alla funzione di comportarsi sia come analogo di \func{unlink} che di
-\func{rmdir}; il suo prototipo è:
+Un utilizzo specifico dell'argomento \param{flags} viene fatto anche dalla
+funzione di sistema \funcd{unlinkat}, in questo caso l'argomento viene
+utilizzato perché tramite esso si può indicare alla funzione di comportarsi
+sia come analogo di \func{unlink} che di \func{rmdir}; il suo prototipo è:
\begin{funcproto}{
\fhead{fcntl.h}
+\fhead{unistd.h}
\fdecl{int unlinkat(int dirfd, const char *pathname, int flags)}
\fdesc{Rimuove una voce da una directory.}
}
Di default il comportamento di \func{unlinkat} è equivalente a quello che
avrebbe \func{unlink} applicata a \param{pathname}, fallendo in tutti i casi
in cui questo è una directory, se però si imposta \param{flags} al valore di
-\const{AT\_REMOVEDIR}, essa si comporterà come \func{rmdir}, in tal
-caso \param{pathname} deve essere una directory, che sarà rimossa qualora
-risulti vuota. Non essendo in questo caso prevista la possibilità di usare
-altri valori (la funzione non segue comunque i collegamenti simbolici) anche
-se \param{flags} è una maschera binaria, essendo \const{AT\_REMOVEDIR} l'unico
-flag disponibile per questa funzione, lo si può assegnare direttamente.
-
-Infine una terza funzione, \funcm{linkat}, utilizza in maniera diversa dalle
-altre l'argomento \param{flags}, anche se in questo caso l'utilizzo continua
-ad essere attinente al comportamento con i collegamenti simbolici. Si ricordi
-che su Linux il comportamento di \func{link} è quello di non seguire mai i
-collegamenti simbolici, pertanto l'uso ordinario dell'argomento parrebbe in
-questo caso essere inutile. A partire dal kernel 2.6.18 invece però è stato
-aggiunta per questa funzione la possibilità di usare il valore
-\const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i collegamenti
-simbolici.
-
-Dato che questo è il comportamento adottato per un valore nullo
-di \param{flags} da tutte le altre funzioni, \func{linkat} è l'unica per cui
-può essere usato esplicitamente questo valore e per la quale non ha senso
-usare \const{AT\_SYMLINK\_NOFOLLOW}. Per avere un quadro d'insieme si è
-riassunto in tab.~\ref{tab:at-functions_constant_values} l'elenco delle
-costanti utilizzabili per i valori di \param{flags}.
+\const{AT\_REMOVEDIR}, essa si comporterà come \func{rmdir}, in tal caso
+\param{pathname} deve essere una directory, che sarà rimossa qualora risulti
+vuota. Non essendo in questo caso prevista la possibilità di usare altri
+valori (la funzione non segue comunque i collegamenti simbolici e
+\const{AT\_EMPTY\_PATH} non è supportato) anche se \param{flags} è una
+maschera binaria, essendo \const{AT\_REMOVEDIR} l'unico flag disponibile per
+questa funzione, lo si può assegnare direttamente.
+
+Un'altra funzione di sistema che usa l'argomento \param{flags} è
+\func{utimensat}, che però non è una corrispondente esatta delle funzioni
+classiche \func{utimes} e \func{lutimes}, in quanto ha una maggiore precisione
+nella indicazione dei tempi dei file, per i quali, come per \func{futimens},
+si devono usare strutture \struct{timespec} che consentono una precisione fino
+al nanosecondo; la funzione è stata introdotta con il kernel
+2.6.22,\footnote{in precedenza, a partire dal kernel 2.6.16, era stata
+ introdotta una \textit{system call} \funcm{futimesat} seguendo una bozza
+ della revisione dello standard poi modificata; questa funzione, sostituita
+ da \func{utimensat}, è stata dichiarata obsoleta, non è supportata da
+ nessuno standard e non deve essere più utilizzata: pertanto non ne
+ parleremo.} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fhead{sys/stat.h}
+\fdecl{int utimensat(int dirfd, const char *pathname, const struct
+ timespec times[2],\\
+\phantom{int utimensat(}int flags)}
+\fdesc{Cambia i tempi di un file.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà i valori di \func{utimes}, \func{lutimes} e
+ \func{futimens} con lo stesso significato ed inoltre:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{dirfd} non è \const{AT\_FDCWD} o un file
+ descriptor valido.
+ \item[\errcode{EFAULT}] \param{dirfd} è \const{AT\_FDCWD} ma
+ \param{pathname} è \var{NULL} o non è un puntatore valido.
+ \item[\errcode{EINVAL}] si usato un valore non valido per \param{flags},
+ oppure \param{pathname} è \var{NULL}, \param{dirfd} non è
+ \const{AT\_FDCWD} e \param{flags} contiene \const{AT\_SYMLINK\_NOFOLLOW}.
+ \item[\errcode{ESRCH}] non c'è il permesso di attraversamento per una delle
+ componenti di \param{pathname}.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione imposta i tempi dei file utilizzando i valori passati nel vettore
+di strutture \struct{timespec} ed ha in questo lo stesso comportamento di
+\func{futimens}, vista in sez.~\ref{sec:file_file_times}, ma al contrario di
+questa può essere applicata anche direttamente ad un file come \func{utimes};
+l'unico valore consentito per \param{flags} è \const{AT\_SYMLINK\_NOFOLLOW}
+che indica alla funzione di non dereferenziare i collegamenti simbolici, cosa
+che le permette di riprodurre anche le funzionalità di \func{lutimes} (con una
+precisione dei tempi maggiore).
+
+Su Linux solo \func{utimensat} è una \textit{system call} mentre
+\func{futimens} è una funzione di libreria, infatti \func{utimensat} ha un
+comportamento speciale se \param{pathname} è \var{NULL}, in tal caso
+\param{dirfd} viene considerato un file descriptor ordinario e il cambiamento
+del tempo viene applicato al file sottostante, qualunque esso sia. Viene cioè
+sempre usato il comportamento che per altre funzioni deve essere attivato con
+\const{AT\_EMPTY\_PATH} (che non è previsto per questa funzione) per cui
+\code{futimens(fd, times}) è del tutto equivalente a \code{utimensat(fd, NULL,
+ times, 0)}. Si tenga presente che nella \acr{glibc} questo comportamento è
+disabilitato, e la funzione, seguendo lo standard POSIX, ritorna un errore di
+\errval{EINVAL} se invocata in questo modo.
+
+Come corrispondente di \func{stat}, \func{fstat} e \func{lstat} si può
+utilizzare invece la funzione di sistema \funcd{fstatat}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fhead{sys/stat.h}
+\fdecl{int fstatat(int dirfd, const char *pathname, struct stat *statbuf, int
+ flags)}
+\fdesc{Legge le informazioni di un file.}
+}
+
+{La funzione ritorna gli stessi valori e gli stessi codici di errore di
+ \func{stat}, \func{fstat}, o \func{lstat} a seconda del valore di
+ \param{flags}, ed in più:
+ \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 \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione ha lo stesso comportamento delle sue equivalenti classiche, l'uso
+di \param{flags} consente di farla comportare come \func{lstat} se si usa
+\const{AT\_SYMLINK\_NOFOLLOW}, o come \func{fstat} se si usa con
+\const{AT\_EMPTY\_PATH} e si passa il file descriptor in \param{dirfd}. Viene
+però supportato l'ulteriore valore \const{AT\_NO\_AUTOMOUNT} che qualora
+\param{pathname} faccia riferimento ad una directory marcata per
+l'\textit{automount} ne evita il montaggio automatico.
+
+Ancora diverso è il caso di \funcd{linkat} anche se in questo caso l'utilizzo
+continua ad essere attinente al comportamento con i collegamenti simbolici, il
+suo prototipo è:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int linkat(int olddirfd, const char *oldpath, int newdirfd, \\
+\phantom{int linkat(}const char *newpath, int flags)}
+\fdesc{Crea un nuovo collegamento diretto (\textit{hard link}).}
+}
+
+{La funzione ritorna gli stessi valori e gli stessi codici di errore di
+ \func{link}, ed in più:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{olddirfd} o \param{newdirfd} non sono un file
+ descriptor valido.
+ \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
+ \item[\errcode{ENOENT}] \param{oldpath} o \param{newpath} è un
+ \textit{pathname} relativo, ma la corrispondente directory di partenza
+ (\param{olddirfd} o \param{newdirfd}) è stata cancellata, oppure si è
+ cercato di creare un \textit{link} da un file descriptor aperto con
+ \const{O\_TMPFILE} e \const{O\_EXCL}, oppure si è usato
+ \const{AT\_EMPTY\_PATH} senza privilegi amministrativi.
+ \item[\errcode{ENOTDIR}] \param{oldpath} e \param{newpath} sono
+ \textit{pathname} relativi, ma \param{olddirfd} o \param{newdirfd} fa
+ riferimento ad un file.
+ \item[\errcode{EPERM}] si è usato \const{AT\_EMPTY\_PATH} con
+ \param{oldpath} vuoto e \param{olddirfd} che fa riferimento ad una
+ directory.
+ \end{errlist}
+}
+\end{funcproto}
+
+Anche in questo caso la funzione svolge lo stesso compito della
+corrispondente classica \func{link}, ma dovendo specificare due
+\textit{pathname} (sorgente e destinazione) aggiunge a ciascuno di essi un
+argomento (rispettivamente \param{olddirfd} e \param{newdirfd}) per poter
+indicare entrambi come relativi a due directory aperte in precedenza.
+
+In questo caso, dato che su Linux il comportamento di \func{link} è quello di
+non seguire mai i collegamenti simbolici, \const{AT\_SYMLINK\_NOFOLLOW} non
+viene utilizzato. A partire dal kernel 2.6.18 è stato aggiunto a questa
+funzione la possibilità di usare il valore \const{AT\_SYMLINK\_FOLLOW} per
+l'argomento \param{flags},\footnote{nei kernel precedenti, dall'introduzione
+ nel 2.6.16, l'argomento \param{flags} era presente, ma senza alcun valore
+ valido, e doveva essere passato sempre con valore nullo.} che richiede di
+dereferenziare un eventuale collegamento simbolico creando un \textit{hard
+ link} al file puntato da quest'ultimo.
+
+Inoltre a partire dal kernel 3.11 si può usare \const{AT\_EMPTY\_PATH} con lo
+stesso significato già visto in precedenza applicato ad \param{olddirfd}, si
+può cioè creare un nuovo \textit{hard link} al file associato al file
+descriptor \param{olddirfd}, passando un valore nullo per
+\param{oldpath}. Questa operazione però è privilegiata e richiede i privilegi
+di amministratore (la \textit{capability} \const{CAP\_DAC\_READ\_SEARCH}),
+infatti in questo modo la funzione si comporta come una ipotetica
+\texttt{flink}, una \textit{system call} di cui è stato spesso chiesta la
+creazione, che permetterebbe di associare direttamente un nome ad un file
+descriptor, ma che non è mai stata realizzata per problemi di sicurezza.
+
+Il problema infatti è che le verifiche di accesso sono fatte quando il file
+viene aperto e non attengono solo ai permessi del file stesso, ma anche a
+quelli delle directory del suo \textit{pathname}; se una volta aperto venisse
+collegato in un altra directory eventuali restrizioni imposte sulle directory
+del suo \textit{pathname} andrebbero perse. Inoltre sarebbe possibile accedere
+al file sottostante anche in scrittura per un file descriptor che è stato
+fornito come aperto in sola lettura, o con accesso libero per un file
+descriptor fornito aperto in \textit{append}. Infine e la funzione
+consentirebbe rendere accessibile all'interno di un \textit{choot} (vedi
+sez.~\ref{sec:file_chroot}) un qualunque file sia stato aperto fuori dallo
+stesso prima di entrarvi.
+
+% NOTE per la discussione sui problemi di sicurezza relativi a questa
+% funzionalità vedi http://lwn.net/Articles/562488/
+
+Per questo motivo l'uso di \const{AT\_EMPTY\_PATH} richiede comunque privilegi
+amministrativi, anche se, quando è disponibile il filesystem \texttt{/proc}, è
+possibile usare \func{linkat} per creare un file da un qualunque file
+descriptor un processo abbia aperto, usandola con un codice analogo al
+seguente:\footnote{non esiste al momento, se si sta usando il filesystem
+ \textit{proc}, una modalità per evitare i rischi illustrati in precedenza.}
+\includecodesnip{listati/procfd_linkat.c}
+e questa modalità è anche quella con cui è possibile assegnare in un secondo
+tempo il nome ad un file anonimo creato usando \func{open} con
+\const{O\_TMPFILE}; ma si deve tenere presente che per questi file la funzione
+ha un comportamento particolare.
+
+In generale infatti quando il file sorgente di \func{linkat} ha un numero di
+collegamenti nulli (cosa che avviene ad esempio quando si apre un file
+temporaneo e lo si cancella subito dopo oppure quando viene cancellato un file
+aperto in precedenza) la funzione non consente di ricollegarlo ad un altro
+file riassegnandogli un nuovo nome e fallisce sempre con un errore di
+\errval{ENOENT} qualunque siano i permessi del processo, e che si usi questo
+approccio o \const{AT\_EMPTY\_PATH}. Ma questo non avviene se il file
+descriptor è stato ottenuto con \const{O\_TMPFILE}, in tal caso la funzione ha
+successo, a meno che non si sia usato nell'apertura anche \const{O\_EXCL} per
+impedire questo comportamento, e continuare ad ottenere \errval{ENOENT}.
+
+In fig.~\ref{fig:initfile} si è riportato il codice della funzione
+\func{InitFile}, che consente di creare in maniera sicura il contenuto
+iniziale di un file utilizzando \const{O\_TMPFILE} e \func{linkat}, come
+accennato a pag.~\pageref{open_o_tmpfile_flag}. La funzione richiede di
+indicare il file da creare usando la sintassi delle \textit{at-functions},
+specificando la directory in cui crearlo con il corrispondente file descriptor
+passato nell'argomento \texttt{dirfd} ed il pathname relativo ed essa passato
+l'argomento \texttt{file}; il contenuto iniziale del file deve essere fornito
+nel buffer \texttt{buf} di lunghezza \texttt{size}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/InitFile.c}
+ \end{minipage}
+ \caption{Esempio di codice per creare in maniera sicura il contenuto
+ iniziale di un file.}
+ \label{fig:initfile}
+\end{figure}
+
+La funzione come primo passo (\texttt{\small 6--10}) ottiene un file
+descriptor accessibile in lettura/scrittura invocando \func{openat} con il
+flag \const{O\_TMPFILE} per ottenere un file anonimo, facendo riferimento a
+quella che sarà la directory di destinazione in cui poi verrà collegato lo
+stesso passata dal chiamante in \texttt{dirfd}, usando ``\texttt{.}'' come
+\textit{pathname} relativo. Si noti come nella chiamata si impostino anche
+(per semplicità si è usato un valore fisso) i valori iniziali dei permessi del
+file (lettura e scrittura solo per il proprietario), e come dopo la chiamata
+si controlli la presenza di un eventuale errore, ritornandolo con un messaggio
+qualora avvenga.
+
+Il secondo passo (\texttt{\small 11--15}) è quello di chiamare la funzione
+\func{FullWrite} (che tratteremo in dettaglio in sez.~\ref{sec:sock_io_behav})
+per eseguire la scrittura del contenuto del buffer \texttt{buf} sul file
+anonimo ottenuto con \func{openat}; in sostanza la funzione scrive tutto il
+contenuto del buffer, iterando le scritture qualora non sia possibile eseguire
+tutto con una singola \func{write}, cosa che comunque per i file su disco in
+genere non avviene mai.
+
+Una volta completata con successo la scrittura l'ultimo passo (\texttt{\small
+ 17--23}) è collegare il file anonimo con \func{linkat}, per questo però
+occorre utilizzare il \textit{pathname} ad esso associato sotto
+\texttt{/proc}, che viene ottenuto (\texttt{\small 16}) con una
+\func{snprintf} (vedi sez.~\ref{sec:file_formatted_io}) usando file descriptor
+restituito da \func{openat}. Con questo \textit{pathname} si può procedere
+(\texttt{\small 17}) a chiamare \func{linkat} per eseguire il collegamento, in
+cui occorre usare il flag \const{AT\_SYMLINK\_NOFOLLOW} come nell'esempio
+precedente.
+
+Altre due funzioni che utilizzano due \textit{pathname} (e due file
+descriptor) sono \funcd{renameat} e \funcd{renameat2}, corrispondenti alla
+classica \func{rename}; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int renameat(int olddirfd, const char *oldpath, int newdirfd, const
+ char *newpath)}
+\fdecl{int renameat2(int olddirfd, const char *oldpath, int newdirfd, \\
+\phantom{int renameat2(}const char *newpath, int flags)}
+\fdesc{Rinomina o sposta un file o una directory.}
+}
+
+{La funzioni ritornano gli stessi valori e gli stessi codici di errore di
+ \func{rename}, ed in più per entrambe:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{olddirfd} o \param{newdirfd} non sono un file
+ descriptor valido.
+ \item[\errcode{ENOTDIR}] \param{oldpath} e \param{newpath} sono
+ \textit{pathname} relativi, ma i corrispondenti \param{oldirfd} o
+ \param{newdirfd} fan riferimento ad un file e non a una directory.
+ \end{errlist}
+ e per \func{renameat2} anche:
+ \begin{errlist}
+ \item[\errcode{EEXIST}] si è richiesto \macro{RENAME\_NOREPLACE} ma
+ \param{newpath} esiste già.
+ \item[\errcode{EINVAL}] Si è usato un flag non valido in \param{flags}, o si
+ sono usati insieme a \macro{RENAME\_EXCHANGE} o \macro{RENAME\_NOREPLACE}
+ o \macro{RENAME\_WHITEOUT}, o non c'è il supporto nel filesystem per una
+ delle operazioni richieste in \param{flags}.
+ \item[\errcode{ENOENT}] si è richiesto \macro{RENAME\_EXCHANGE} e
+ \param{newpath} non esiste.
+ \item[\errcode{EPERM}] si è richiesto \macro{RENAME\_WHITEOUT} ma il
+ chiamante non ha i privilegi di amministratore.
+ \end{errlist}
+}
+\end{funcproto}
+
+In realtà la corrispondente di \func{rename}, prevista dallo standard
+POSIX.1-2008 e disponibile dal kernel 2.6.16 come le altre
+\textit{at-functions}, sarebbe soltanto \func{renameat}, su Linux però, a
+partire dal kernel dal 3.15, questa è stata realizzata in termini della nuova
+funzione di sistema \func{renameat2} che prevede l'uso dell'argomento
+aggiuntivo \param{flags}; in questo caso \func{renameat} è totalmente
+equivalente all'utilizzo di \func{renamat2} con un valore nullo per
+\param{flags}.
+
+L'uso di \func{renameat} è identico a quello di \func{rename}, con la sintassi
+delle \textit{at-functions} applicabile ad entrambi i \textit{pathname} passati
+come argomenti alla funzione. Con \func{renameat2} l'introduzione
+dell'argomento \func{flags} (i cui valori possibili sono riportati in
+tab.~\ref{tab:renameat2_flag_values}) ha permesso di aggiungere alcune
+funzionalità specifiche di Linux non previste al momento da nessuno standard
+(la funzione è disponibile nelle \acr{glibc} a partire dalla versione 2.28).
\begin{table}[htb]
\centering
\textbf{Costante} & \textbf{Significato} \\
\hline
\hline
- \constd{AT\_SYMLINK\_NOFOLLOW}& Se impostato la funzione non esegue la
- dereferenziazione dei collegamenti
- simbolici.\\
- \constd{AT\_SYMLINK\_FOLLOW}& Se impostato la funzione esegue la
- dereferenziazione dei collegamenti simbolici
- (usato esplicitamente solo da
- \func{linkat}).\\
- \constd{AT\_EACCES} & Usato solo da \func{faccessat}, richiede che
- il controllo dei permessi sia fatto usando
- l'\ids{UID} effettivo invece di quello
- reale.\\
- \constd{AT\_REMOVEDIR} & Usato solo da \func{unlinkat}, richiede che
- la funzione si comporti come \func{rmdir}
- invece che come \func{unlink}.\\
+ \const{RENAME\_EXCHANGE} & richiede uno scambio di nomi fra
+ \param{oldpath} e \param{newpath}, non è
+ usabile con \const{RENAME\_NOREPLACE}.\\
+ \const{RENAME\_NOREPLACE}& non sovrascrive \param{newpath} se questo
+ esiste dando un errore.\\
+ \const{RENAME\_WHITEOUT} & crea un oggetto di \textit{whiteout}
+ contestualmente al cambio di nome
+ (disponibile a partire dal kernel 3.18).\\
\hline
\end{tabular}
- \caption{Le costanti utilizzate per i bit dell'argomento
- aggiuntivo \param{flags} delle \textit{at-functions}.}
- \label{tab:at-functions_constant_values}
+ \caption{I valori specifici dei bit dell'argomento \param{flags} per l'uso
+ con \func{renameat2}.}
+ \label{tab:renameat2_flag_values}
+\end{table}
+
+L'uso dell'argomento \param{flags} in questo caso non attiene alle
+funzionalità relative alla \textit{at-functions}, ma consente di estendere le
+funzionalità di \func{rename}. In particolare \func{renameat2} consente di
+eseguire uno scambio di nomi in maniera atomica usando il flag
+\constd{RENAME\_EXCHANGE}; se specificato la funzione rinomina in un colpo
+solo \param{oldpath} in \param{newpath} e \param{newpath} in
+\param{oldpath}. Usando questo flag, entrambi i \textit{pathname} passati come
+argomenti devono esistere, e non è possibile usare \const{RENAME\_NOREPLACE},
+non ci sono infine restrizioni sul tipo di file (regolare, directory, link
+simbolici, dispositivo) di cui si scambia il nome.
+
+Il flag \constd{RENAME\_NOREPLACE} consente di richiedere la generazione di un
+errore nei casi in cui \func{rename} avrebbe causato una sovrascrittura della
+destinazione, rendendo possibile evitare la stessa in maniera atomica; un
+controllo preventivo dell'esistenza del file infatti avrebbe aperto alla
+possibilità di una \textit{race condition} fra il momento del controllo e
+quella del cambio di nome.
+
+\itindbeg{overlay~filesytem}
+\itindbeg{union~filesytem}
+
+Infine il flag \constd{RENAME\_WHITEOUT}, introdotto con il kernel 3.18,
+richiede un approfondimento specifico, in quanto attiene all'uso della
+funzione con dei filesystem di tipo \textit{overlay}/\textit{union}, dato che
+il flag ha senso solo quando applicato a file che stanno su questo tipo di
+filesystem. Un \textit{overlay} o \textit{union filesystem} è un filesystem
+speciale strutturato in livelli, in cui si rende scrivibile un filesystem
+accessibile in sola lettura, \textsl{sovrapponendogli} un filesystem
+scrivibile su cui vanno tutte le modifiche. Un tale tipo di filesystem serve
+ad esempio a rendere scrivibili i dati processati quando si fa partire una
+distribuzione \textit{Live} basata su CD o DVD, ad esempio usando una
+chiavetta o uno spazio disco aggiuntivo.
+
+In questo caso quando si rinomina un file che sta nello strato in sola lettura
+questo viene copiato a destinazione sulla parte accessibile in scrittura, ma
+l'originale non può essere cancellato; per far si che esso non appaia più è
+possibile creare un oggetto speciale del filesystem, chiamato
+\textit{whiteout}, che serve a renderlo non più visibile. La funzione consente
+di creare questo oggetto, che in un filesystem ordinario verrebbe visto come
+un file di dispositivo con \textit{major minor} e \textit{minor number} nulli,
+in maniera atomica quando si rinomina un file. Dato che l'uso di
+\const{RENAME\_WHITEOUT} comporta in sostanza la creazione di un file di
+dispositivo, l'operazione è privilegiata (occorre la \textit{capability}
+\const{CAP\_MKNOD}), inoltre occorre anche il supporto nel filesystem usato
+come supporto per la scrittura. Infine l'operazione non è compatibile con
+\const{RENAME\_EXCHANGE}.
+
+\itindend{overlay~filesytem}
+\itindend{union~filesytem}
+
+Benché non rientri nelle \textit{at-functions} previste nello standard
+POSIX.1-2008, tratteremo qui anche la funzione di sistema \funcd{statx},
+introdotta con il kernel 4.11 e disponibile dalle versione 2.28 della
+\acr{glibc}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/stat.h}
+\fhead{unistd.h}
+\fhead{fcntl.h}
+\fdecl{int statx(int dirfd, const char *pathname, int flags, \\
+\phantom{int statx(}unsigned int mask, struct statx *statxbuf)}
+\fdesc{Legge le informazioni di un file.}
+}
+
+{La funzione ritorna gli stessi valori e gli stessi codici di errore di
+ \func{stat}, \func{fstat}, o \func{lstat} a seconda del valore di
+ \param{flags}, ed in più:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+ \item[\errcode{EINVAL}] \param{flags} non ha un valore valido o \param{mask}
+ ha un valore riservato.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione è una estensione specifica di Linux consente di leggere le
+informazioni di un file; ha la stessa sintassi di \func{fstatat} utilizzando
+con lo stesso significato gli argomenti \param{dirfd} e \param{pathname} ed i
+valori \const{AT\_EMPTY\_PATH}, \const{AT\_NO\_AUTOMOUNT} e
+\const{AT\_SYMLINK\_NOFOLLOW} per \param{flags}. Si può pertanto indicare il
+file di cui si vogliono ottenere i dati con un \textit{pathname} assoluto, con
+un \textit{pathname} relativo (sia alla directory corrente che a quella
+indicata da \param{dirfd}) o con un file descriptor ad esso associato.
+
+La funzione però consente di ottenere informazioni più dettagliate rispetto a
+quelle fornite dalle funzioni tradizionali come \func{stat} e \func{fstatat},
+ed è in grado di controllare le modalità con cui le ottiene nel caso un file
+sia posto su un filesystem remoto. Per questo, oltre ai tre valori
+precedenti, l'argomento \param{flags} consente anche gli ulteriori valori
+elencati in tab.~\ref{tab:statx_flags_const}, con il significato ivi
+illustrato.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{AT\_STATX\_SYNC\_AS\_STAT}& si comporta esattamente come
+ \func{stat}, in questo caso (il default
+ se non viene indicato niente) il
+ risultato dipende dal tipo di
+ filesystem.\\
+ \constd{AT\_STATX\_FORCE\_SYNC}& richiede che i valori degli attributi
+ richiesti siano, in caso di un filesystem
+ di rete, siano sincronizzati con il server
+ remoto, questo può forzare una scrittura
+ dei dati (in particolare i tempi del file)
+ verso lo stesso.\\
+ \constd{AT\_STATX\_DONT\_SYNC} & chiede di non sincronizzare nessun dato,
+ ritornando quanto presente nella cache,
+ questo significa che i dati potrebbero
+ essere non coerenti ed aggiornati, ma si
+ evita, in caso di filesystem di rete, la
+ necessità di contattare il server remoto.\\
+ \hline
+ \end{tabular}
+ \caption{Valori specifici di \func{statx} per l'argomento \param{flags}.}
+ \label{tab:statx_flags_const}
+\end{table}
+
+La funzione restituisce le informazioni relative al file richiesto nella
+struttura \struct{statx} puntata dall'argomento \param{statxbuf}. Inoltre
+data la quantità di informazioni che possono essere richieste, la funzione
+consente, con l'argomento \param{mask} di selezionare quelle volute, questa
+deve essere assegnata ad una maschera binaria dei valori illustrati in
+tab.~\ref{tab:statx_mask_const}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{STATX\_TYPE} & Tipo del file (\texttt{stx\_mode \& S\_IFMT}).\\
+ \constd{STATX\_MODE} & Permessi del file (\texttt{stx\_mode \&
+ \tild{}S\_IFMT}).\\
+ \constd{STATX\_NLINK} & Numero di collegamenti (\textit{hard link},
+ \texttt{stx\_nlink}).\\
+ \constd{STATX\_UID} & Proprietario del file (per \ids{UID},
+ \texttt{stx\_uid}).\\
+ \constd{STATX\_GID} & Gruppo proprietario del file (per \ids{GID},
+ \texttt{stx\_gid}).\\
+ \constd{STATX\_ATIME} & Tempo di ultimo accesso (\texttt{stx\_atime}).\\
+ \constd{STATX\_MTIME} & Tempo di ultima modifica (\texttt{stx\_mtime}).\\
+ \constd{STATX\_CTIME} & Tempo di ultimo cambiamento (\texttt{stx\_ctime}).\\
+ \constd{STATX\_INO} & Numero di \textit{inode} (\texttt{stx\_ino}).\\
+ \constd{STATX\_SIZE} & Dimensione del file (\texttt{stx\_size}).\\
+ \constd{STATX\_BLOCKS}& Numero di blocchi del file (\texttt{stx\_blocks}).\\
+ \constd{STATX\_BASIC\_STATS}& Tutte le informazioni precedenti.\\
+ \constd{STATX\_BTIME} & Tempo di creazione (\texttt{stx\_btime}).\\
+% \constd{}& .\\
+ \constd{STATX\_ALL} & Tutte le informazioni.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti per i valori dell'argomento \param{mask} di
+ \func{statx}.}
+ \label{tab:statx_mask_const}
\end{table}
+Si tenga presente che il kernel non richiede che \param{mask} contenga solo i
+flag di tab.~\ref{tab:statx_mask_const}, valori ulteriori in genere vengono
+ignorati ma non si può comunque indicare un valore qualunque in quanto alcuni
+bit sono riservati per future estensioni.\footnote{in particolare il bit
+ \constd{STATX\_\_RESERVED} che se usato causa il fallimento della funzione
+ con un errore di \errval{EINVAL}.} Inoltre non è detto che tutte le
+informazioni richieste con \param{mask} siano disponibili, per questo il
+kernel restituisce in un opportuno campo della struttura \struct{statx},
+\var{stx\_mask}, quali sono i dati effettivamente restituiti, che possono in
+alcuni casi essere anche di più di quelli richiesti (se l'informazione
+aggiuntiva è ottenuta senza costi ulteriori) per cui è normale che questo
+valore possa essere diverso da quanto richiesto.
-Un'ultima differenza fra le \textit{at-functions} e le funzioni tradizionali
-di cui sono estensione è, come accennato in sez.~\ref{sec:file_temp_file},
-quella relativa a \funcm{utimensat} che non è propriamente una corrispondente
-esatta di \func{utimes} e \func{lutimes}, dato che questa funzione ha una
-maggiore precisione nella indicazione dei tempi dei file, per i quali come per
-\func{futimes}, si devono usare strutture \struct{timespec} che consentono una
-precisione fino al nanosecondo.
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/statx.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{statx} per la lettura delle informazioni dei
+ file.}
+ \label{fig:file_statx_struct}
+\end{figure}
-% NOTA: manca prototipo di utimensat, per ora si lascia una menzione
+Si è riportata in fig.~\ref{fig:file_statx_struct} la definizione della
+struttura \struct{statx} come presente in \headfile{sys/stat.h}; i campi
+\var{stx\_mode}, \var{stx\_nlink}, \var{stx\_uid}, \var{stx\_gid},
+\var{stx\_ino}, \var{stx\_size}, \var{stx\_blksize}, \var{stx\_blocks} sono
+identici agli analoghi (con prefisso \texttt{st\_}) dell'ordinaria struttura
+\struct{stat} illustrata in fig.~\ref{fig:file_stat_struct} e vale per essi
+quanto già detto in sez.~\ref{sec:file_stat} e seguenti.
-\itindend{at-functions}
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/statx_timestamp.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{statx\_timestamp} per i tempi dei file con
+ \func{statx}. }
+ \label{fig:file_statx_timestamp_struct}
+\end{figure}
+
+Anche i campi \var{stx\_atime}, \var{stx\_mtime}, \var{stx\_ctime} mantengono
+questa analogia, ma esprimono i tempi di ultimo accesso, modifica e
+cambiamento con una precisione ed estensione maggiore grazie all'uso di una
+struttura dedicata \struct{statx\_timestamp} (riportata in
+fig.~\ref{fig:file_statx_timestamp_struct}) che consente di estendere i tempi
+dei file ad una granularità del nanosecondo e con un valore dello \textit{unix
+ time} (vedi sez.~\ref{sec:sys_unix_time}) a 64 bit, che non darà problemi di
+overflow per parecchio tempo (sicuramente ben oltre la durata di questa
+guida).
+
+Oltre ai precedenti, e a \val{stx\_mask} che abbiamo già visto e che indica
+quali delle informazioni richieste alla funzione sono state fornite,
+\func{statx} prevede una serie di informazioni aggiuntive fornite in
+altrettanti nuovi campi, illustrati nell'elenco seguente. È comunque previsto
+che in futuro \struct{statx} venga estesa per supportare ulteriori
+informazioni.
+
+\begin{basedescript}{\desclabelwidth{1.6cm}\desclabelstyle{\nextlinelabel}}
+\item[\var{stx\_btime}] In questo campo viene restituito il \textsl{tempo di
+ creazione} del file. Come detto in sez.~\ref{sec:file_file_times} questo
+ tempo normalmente non esiste in un sistema \textit{unix-like}, ma per
+ migliorare l'interoperabilità è stato aggiunto nelle versioni più recenti di
+ vari filesystem (come XFS, \acr{ext4}, ecc.) in modo che possa essere
+ utilizzato da servizi di condivisione dei file (è usato da \textsl{Samba},
+ ed è previsto nello standard di NFSv4).
+\item[\var{stx\_attributes\_mask}] in questo campo viene restituita una
+ maschera che indica quali sono i bit restituiti in \var{stx\_attributes}
+ effettivamente supportati per il file, e per poter utilizzare quest'ultimo
+ occorre sempre eseguire un AND aritmetico con \var{stx\_attributes\_mask} per
+ ottenere i valori validi.
+\item[\var{stx\_attributes}] in questo campo vengono restituiti gli eventuali
+ attributi addizionali posseduti dal file. Gran parte di questi sono quelli
+ impostati con i comandi \cmd{lsattr} e \cmd{chattr} ed abbiamo già incontrato
+ alcuni di essi in sez.~\ref{sec:file_perm_overview}. Gli attributi vengono
+ restituiti in forma di maschera binaria con i valori delle costanti elencate
+ in tab.~\ref{tab:statx_stx_attributes}, dove si trova anche la relativa
+ descrizione.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{STATX\_ATTR\_COMPRESSED}& Il file è compresso automaticamente dal
+ filesystem (quindi può richiedere un
+ maggior uso di risorse in caso di
+ accesso).\\
+ \constd{STATX\_ATTR\_IMMUTABLE} & Il file è marcato come
+ \textit{immutable} e non può essere
+ modificato in nessun modo (vedi
+ sez.~\ref{sec:file_perm_overview}).\\
+ \constd{STATX\_ATTR\_APPEND} & Il file è marcato come
+ \textit{append-only} e può essere
+ soltanto esteso in \textit{append} (vedi
+ sez.~\ref{sec:file_perm_overview}).\\
+ \constd{STATX\_ATTR\_NODUMP} & Il file è marcato per essere escluso da
+ eventuali backup a livello di filesystem
+ come quelli eseguiti con il comando
+ \cmd{dump}.\\
+ \constd{STATX\_ATTR\_ENCRYPTED} & Il file è cifrato sul filesystem ed è
+ necessaria una chiave di accesso per
+ decifrarne il contenuto.\\
+ \constd{STATX\_ATTR\_AUTOMOUNT} & Il file, in questo caso in genere una
+ directory, è marcata come punto di
+ innesco per un \textit{automount}.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti degli attributi addizionali restituiti in
+ \var{stx\_attributes}.}
+ \label{tab:statx_stx_attributes}
+\end{table}
+
+\item[\var{stx\_rdev\_major}, \var{stx\_rdev\_minor}] in questi campi vengono
+ restituiti rispettivamente \textit{major number} e \textit{minor number} del
+ file quando questo è un file di dispositivo (fanno le veci del campo
+ \var{st\_rdev} di \struct{stat}).
+
+\item[\var{stx\_dev\_major}, \var{stx\_dev\_minor}] in questi campi vengono
+ restituiti \textit{major number} e \textit{minor number} del dispositivo su
+ cui risiede il file (fanno le veci del campo \var{st\_dev} di \struct{stat}).
+\end{basedescript}
+
+Di questi campi \var{stx\_mode}, \var{stx\_nlink}, \var{stx\_uid},
+\var{stx\_gid}, \var{stx\_ino}, \var{stx\_size} e \var{stx\_blocks} e quelli
+relativi ai tempi ordinari dei file vengono sempre restituiti, ed il relativo
+valore in \struct{statx} sovrascritto, indipendentemente dal fatto che siano
+stati richiesti o no, con \var{stx\_mask} che indicherà quali sono quelli che
+hanno valori effettivamente validi.
+
+Se un filesystem ha dei campi che non esistono o hanno valori senza
+corrispondenza in un sistema unix-like, questi potranno essere restituiti con
+valori fittizi ricostruiti, ad esempio usando \ids{UID} e \ids{GID} impostati
+in fase di montaggio per un filesystem che non supporta gli utenti; in questi
+casi il relativo bit in \var{stx\_mask} sarà comunque cancellato. In caso di
+cambiamenti al file eseguiti in concorrenza a \func{statx} è possibile che
+campi diversi possano avere informazioni ottenute in momenti diversi, con
+valori precedenti o posteriori il cambiamento. Inoltre, se non richiesti
+esplicitamente, alcuni campi possono avere valori approssimati, ad esempio in
+caso di NFS, questi non vengono mai aggiornati dallo stato sul server remoto.
+
+Il campo \var{stx\_btime} viene restituito solo se richiesto, e si otterrà un
+valore nullo (ed il relativo bit in \var{stx\_mask} cancellato) se questo non
+esiste. Lo stesso vale nel caso si siano richiesti \var{stx\_rdev\_major} o
+\var{stx\_rdev\_minor} ed il file non è un file di dispositivo. I campi
+\var{stx\_dev\_major}, \var{stx\_dev\_minor} e \var{stx\_blksize} attengono
+ad informazioni locali, e sono sempre disponibili in maniera diretta.
+
+% NOTE: per statx https://lwn.net/Articles/707602/ e
+% https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f)
+
+Infine trattiamo qui altre due funzioni, \func{fexecve} e \func{execveat}, che
+non attengono che in maniera indiretta all'uso dei file, ma sono comunque
+legate all'interfaccia delle \textit{at-functions}. In realtà la sola
+effettivamente collegata all'interfaccia delle \textit{at-functions} è la
+funzione di sistema \func{execveat}, introdotta con il kernel 3.19, e per la
+quale non è disponibile ancora un'interfaccia diretta nella \acr{glibc} che
+però la usa (quando disponibile) per realizzare \func{fexecve}.
+
+L'introduzione di queste funzioni nasce dall'esigenza di verificare i
+contenuti di un file eseguibile prima di eseguirlo. Fare il controllo (aprendo
+il file e verificandone il contenuto) e poi eseguirlo con \func{execve} è
+suscettibile alla possibilità che fra il controllo e l'esecuzione il nome del
+file o di una directory sovrastante venga cambiato.
+
+Per mitigare il problema nello standard POSIX.1-2008 è stata introdotta la
+funzione \funcd{fexecve} che consente di eseguire un programma usando un file
+descriptor al posto di un \textit{pathname}; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int fexecve(int fd, char *const argv[], char *const envp[])}
+\fdesc{Esegue un programma da un file descriptor.}
+}
+
+{La funzione non ritorna in caso di successo e ritorna $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{fd} non è un file descriptor, o \param{argv}
+ o \param{envp} sono \val{NULL}.
+ \item[\errcode{ENOSYS}] il filesystem \file{proc} non è disponibile (prima
+ del kernel 3.19).
+ \end{errlist}
+ oltre a tutti gli errori già visti per \func{execve}.}
+\end{funcproto}
+
+La funzione esegue il programma contenuto nel file (su cui il chiamante deve
+avere il permesso di esecuzione) corrispondente a \param{fd}; questo deve
+essere stato ottenuto aprendo il relativo eseguibile in sola lettura o con
+\const{O\_PATH}. Questa funzione fino al kernel 3.19 veniva realizzata nella
+\acr{glibc} usando il filesystem \file{/proc} per ottenere da \param{fd} il
+file corrispondente in \file{/proc/self/fd/}, in maniera analoga a quanto
+visto per l'esempio di fig.~\ref{fig:initfile}.
+
+La funzione di sistema \funcd{execveat} è stata introdotta proprio per rendere
+più sicura l'esecuzione ed evitare la necessità di avere disponibile
+\file{/proc} per poter usare \func{fexecve}, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int execveat(int dirfd, const char *pathname, char *const argv[], \\
+\phantom{int execveat(}char *const envp[], int flags)}
+\fdesc{Esegue un programma relativo ad una directory.}
+}
+
+{La funzione non ritorna in caso di successo e ritorna $-1$ per un errore, nel
+ qual caso \var{errno} assumerà, inoltre tutti gli errori già visti per
+ \func{execve}, uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor valido.
+ \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
+ \item[\errcode{ELOOP}] si è usato \const{AT\_SYMLINK\_NOFOLLOW} in
+ \param{flags} ma il file indicato è un link simbolico.
+ \item[\errcode{ENOENT}] il programma di cui si è richiesta l'esecuzione è
+ uno script, ma \func{dirfd} è aperto con il flag di
+ \textit{close-on-exec} e pertanto il programma non sarebbe accessibile
+ all'interprete.
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione segue la sintassi delle \textit{at-functions} per indicare il file
+da eseguire, e per il resto si comporta esattamente con come \func{execve} (le
+cui caratteristiche sono già state illustrate in
+sez.~\ref{sec:proc_exec}). Diventa così possibile indicare il programma da
+eseguire sia con un \textit{pathname} assoluto che relativo (usando
+\const{AT\_FDCWD} come \param{dirfd}), oppure con un \textit{pathname}
+relativo alla directory indicata da \param{dirfd}. In quest'ultima forma l'uso
+della funzione consente estendere i vantaggi delle \textit{at-functions} anche
+al caso dell'esecuzione di un programma.
+
+Inoltre usando, per \param{flags} il valore \const{AT\_EMPTY\_PATH}, si può
+indicare direttamente il file da eseguire aprendolo e passandone il file
+descriptor nell'argomento \param{dirfd}, ottenendo il comportamento di
+\func{fexecve}; quest'ultima infatti è sostanzialmente equivalente
+all'esecuzione di:
+\includecodesnip{listati/fexecve.c}
+l'unico altro valore utilizzabile per \param{flags} è
+\const{AT\_SYMLINK\_NOFOLLOW}, che fa fallire la funzione con un errore di
+\errval{ELOOP} se il file indicato è un link simbolico.
+
+Quando si usano \func{execveat} o \func{fexecve} per eseguire un programma
+attraverso un file descriptor è naturale impostare sullo stesso il flag di
+\textit{close-on-exec} in modo che questo venga automaticamente chiuso
+all'esecuzione. Questo evita di lasciare aperto inutilmente un file descriptor
+(un programma in genere non ha bisogno di avere un file aperto su se stesso),
+ma soprattutto evita problemi in caso di un eventuale uso ricorsivo di queste
+funzioni, in tal caso infatti, restando aperto ad ogni iterazione un ulteriore
+file descriptor, si potrebbe arrivare all'esaurimento degli stessi.
+
+Tutto questo però non è vero quando si vuole eseguire uno script; in tal caso
+infatti (si ricordi quanto detto a questo riguardo in
+sez.~\ref{sec:proc_exec}) il programma che viene effettivamente messo in
+esecuzione è l'interprete indicato nella riga iniziale dello script, che poi
+legge ed interpreta il codice da eseguire dallo script stesso. Ma se lancia lo
+script usando un file descriptor su cui è attivo il flag di
+\textit{close-on-exec}, questo sarà già chiuso quando l'interprete viene posto
+in esecuzione, rendendo impossibile la lettura del programma da
+interpretare.
+
+Per questo motivo, quando ci si trova in questa situazione, \func{execveat} (e
+quindi anche \func{fexecve}) eseguono un controllo preventivo e falliscono con
+un errore di \errval{ENOENT}. Pertanto se si vuole eseguire uno script
+passandone il file descriptor l'unica possibilità è non attivare il flag di
+\textit{close-on-exec}, esponendosi però al rischio di incorrere nei problemi
+accennati in precedenza.
% TODO: manca prototipo e motivazione di fexecve, da trattare qui in quanto
% inserita nello stesso standard e da usare con openat, vedi
% http://pubs.opengroup.org/onlinepubs/9699939699/toc.pdf
-% TODO: manca prototipo e motivazione di execveat, vedi
-% http://man7.org/linux/man-pages/man2/execveat.2.html
+% TODO manca prototipo di execveat, introdotta nel 3.19, vedi
+% https://lwn.net/Articles/626150/ cerca anche fexecve
+
+
+% TODO: trattare i nuovi AT_flags quando e se arriveranno, vedi
+% https://lwn.net/Articles/767547/
+
+\itindend{at-functions}
-\subsection{Le operazioni di controllo}
+
+\subsection{Le operazioni di controllo sui file descriptor}
\label{sec:file_fcntl_ioctl}
Oltre alle operazioni base esaminate in sez.~\ref{sec:file_unix_interface}
caratteristiche di un file descriptor, viene usata la funzione di sistema
\funcd{fcntl},\footnote{ad esempio si gestiscono con questa funzione varie
modalità di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_operation}) e
- il \textit{file locking} (vedi sez.~\ref{sec:file_locking}).} il cui
-prototipo è:
+ il \textit{file locking} (vedi sez.~\ref{sec:file_locking}) e altre
+ funzionalità avanzate che tratteremo più avanti.} il cui prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
\fhead{fcntl.h}
\fdecl{int fcntl(int fd, int cmd)}
-\fdecl{int fcntl(int fd, int cmd, long arg)}
-\fdecl{int fcntl(int fd, int cmd, struct flock * lock)}
-\fdecl{int fcntl(int fd, int cmd, struct f\_owner\_ex * owner)}
-\fdesc{Esegue una operazione di controllo sul file.}
+\fdecl{int fcntl(int fd, int cmd, int arg)}
+\fdecl{int fcntl(int fd, int cmd, ...)}
+\fdesc{Esegue una operazione di controllo su un file descriptor.}
}
{La funzione ha valori di ritorno diversi a seconda dell'operazione richiesta
in caso di successo mentre ritorna sempre $-1$ per un errore, nel qual caso
\var{errno} assumerà valori diversi che dipendono dal tipo di operazione,
- l'unico valido in generale è:
+ gli unici con significato generico sono:
\begin{errlist}
\item[\errcode{EBADF}] \param{fd} non è un file aperto.
+ \item[\errcode{EINVAL}] \param{cmd} non è un comando supportato dal kernel
+ corrente.
\end{errlist}
}
\end{funcproto}
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
-aggiuntivi, sono determinati dal valore dell'argomento \param{cmd} che in
-sostanza corrisponde all'esecuzione di un determinato \textsl{comando}. A
-seconda del comando specificato il terzo argomento può essere assente (ma se
-specificato verrà ignorato), può assumere un valore intero di tipo
-\ctyp{long}, o essere un puntatore ad una struttura \struct{flock}.
+aggiuntivi, sono determinati dal valore del secondo argomento \param{cmd}, che
+serve a specificare il ``\textsl{comando}'' della funzione, in sostanza quale
+operazione si intende eseguire. A seconda del comando richiesto il terzo
+argomento può essere assente (ma se specificato lo stesso verrà semplicemente
+ignorato) ed in generale dipende dal comando \param{cmd}; il caso più comune è
+quello di un intero, ma ci sono comandi in cui si devono usare dei tipi
+specifici, che descriveremo esplicitamente nei singoli casi.
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
il nome indicato nel precedente prototipo), è riportata di seguito:
\begin{basedescript}{\desclabelwidth{1.8cm}}
\item[\constd{F\_DUPFD}] trova il primo file descriptor disponibile di valore
- maggiore o uguale ad \param{arg}, e ne fa un duplicato
- di \param{fd}, ritorna il nuovo file descriptor in caso di successo e $-1$
- in caso di errore. Oltre a \errval{EBADF} gli errori possibili sono
+ maggiore o uguale all'argomento \param{arg}, e ne fa un duplicato di
+ \param{fd}, ritorna il nuovo file descriptor in caso di successo e $-1$ in
+ caso di errore. Oltre a \errval{EBADF} 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.
-\itindbeg{close-on-exec}
-
\item[\constd{F\_DUPFD\_CLOEXEC}] ha lo stesso effetto di \const{F\_DUPFD}, ma
in più attiva il flag di \textit{close-on-exec} sul file descriptor
duplicato, in modo da evitare una successiva chiamata con
sez.~\ref{sec:intro_gcc_glibc_std}).
\item[\constd{F\_GETFD}] restituisce il valore dei \textit{file descriptor
- flags} di \param{fd} in caso di successo o $-1$ in caso di errore, il
- terzo argomento viene ignorato. Non sono previsti errori diversi da
- \errval{EBADF}. Al momento l'unico flag usato è quello di
- \textit{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 sez.~\ref{sec:proc_exec}). Un valore nullo significa
- pertanto che il flag non è impostato.
+ flags} (vedi sez.~\ref{sec:file_shared_access}) di \param{fd} in caso di
+ successo o $-1$ in caso di errore, il terzo argomento viene ignorato. Non
+ sono previsti errori diversi da \errval{EBADF}. Al momento l'unico flag
+ usato è quello di \textit{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 sez.~\ref{sec:proc_exec}). Un valore
+ nullo significa pertanto che il flag non è impostato.
\item[\constd{F\_SETFD}] imposta il valore dei \textit{file descriptor flags}
- al valore specificato con \param{arg}, ritorna un valore nullo in caso di
- successo e $-1$ in caso di errore. Non sono previsti errori diversi da
- \errval{EBADF}. Dato che l'unico flag attualmente usato è quello di
- \textit{close-on-exec}, identificato dalla costante \const{FD\_CLOEXEC},
- tutti gli altri bit di \param{arg}, anche se impostati, vengono
- ignorati.\footnote{questo almeno è quanto avviene fino al kernel 3.2, come
- si può evincere dal codice della funzione \texttt{do\_fcntl} nel file
- \texttt{fs/fcntl.c} dei sorgenti del kernel.}
-\itindend{close-on-exec}
+ (vedi sez.~\ref{sec:file_shared_access}) al valore specificato con
+ \param{arg}, ritorna un valore nullo in caso di successo e $-1$ in caso di
+ errore. Non sono previsti errori diversi da \errval{EBADF}. Dato che l'unico
+ flag attualmente usato è quello di \textit{close-on-exec}, identificato
+ dalla costante \const{FD\_CLOEXEC}, tutti gli altri bit di \param{arg},
+ anche se impostati, vengono ignorati.\footnote{questo almeno è quanto
+ avviene fino al kernel 3.2, come si può evincere dal codice della funzione
+ \texttt{do\_fcntl} nel file \texttt{fs/fcntl.c} dei sorgenti del kernel.}
\item[\constd{F\_GETFL}] ritorna il valore dei \textit{file status flags} di
\param{fd} in caso di successo o $-1$ in caso di errore, il terzo argomento
dell'argomento \param{flags} di \func{open} che vengono memorizzati nella
relativa voce della \textit{file table} all'apertura del file, vale a dire
quelli riportati in tab.~\ref{tab:open_access_mode_flag} e
- tab.~\ref{tab:open_operation_flag}). Si ricordi che quando si usa la
- funzione per determinare le modalità di accesso con cui è stato aperto il
- file è necessario estrarre i bit corrispondenti nel \textit{file status
- flag} con la maschera \const{O\_ACCMODE} come già accennato in
- sez.~\ref{sec:file_open_close}.
+ tab.~\ref{tab:open_operation_flag}).
+
+ Si ricordi che quando si usa la funzione per determinare le modalità di
+ accesso con cui è stato aperto il file è necessario estrarre i bit
+ corrispondenti nel \textit{file status flag} con la maschera
+ \const{O\_ACCMODE} come già accennato in sez.~\ref{sec:file_open_close}.
\item[\constd{F\_SETFL}] imposta il valore dei \textit{file status flags} al
valore specificato da \param{arg}, ritorna un valore nullo in caso di
successo o $-1$ in caso di errore. In generale possono essere impostati solo
i flag riportati in tab.~\ref{tab:open_operation_flag}, su Linux si possono
modificare soltanto \const{O\_APPEND}, \const{O\_ASYNC}, \const{O\_DIRECT},
- \const{O\_NOATIME} e \const{O\_NONBLOCK}. Oltre a \errval{EBADF} si otterrà
- \errcode{EPERM} se si cerca di rimuovere \const{O\_APPEND} da un file
- marcato come \textit{append-only} o se di cerca di impostare
- \const{O\_NOATIME} su un file di cui non si è proprietari (e non si hanno i
- permessi di amministratore) ed \errcode{EINVAL} se si cerca di impostare
- \const{O\_DIRECT} su un file che non supporta questo tipo di operazioni.
-
-\item[\constd{F\_GETLK}] richiede un controllo sul file lock specificato da
- \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. Come
- per i due successivi comandi oltre a \errval{EBADF} se \param{lock} non è un
- puntatore valido restituisce l'errore generico \errcode{EFAULT}. Questa
- funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
+ \const{O\_NOATIME} e \const{O\_NONBLOCK}.
+
+ Oltre a \errval{EBADF} si otterrà \errcode{EPERM} se si cerca di rimuovere
+ \const{O\_APPEND} da un file marcato come \textit{append-only} o se di cerca
+ di impostare \const{O\_NOATIME} su un file di cui non si è proprietari (e
+ non si hanno i permessi di amministratore) ed \errcode{EINVAL} se si cerca
+ di impostare \const{O\_DIRECT} su un file che non supporta questo tipo di
+ operazioni.
+
+\item[\constd{F\_GETLK}] richiede un controllo sul \textit{file lock}
+ specificato nella struttura \struct{flock} puntata dal terzo argomento (che
+ pertanto dovrà essere di tipo \ctyp{struct flock *}) sovrascrivendone il
+ contenuto con il risultato; ritorna un valore nullo in caso di successo o
+ $-1$ in caso di errore. Come per i due successivi comandi oltre a
+ \errval{EBADF}, se il terzo argomento non è un puntatore valido, restituisce
+ l'errore generico \errcode{EFAULT}. Questa funzionalità è trattata in
+ dettaglio in sez.~\ref{sec:file_posix_lock}.
-\item[\constd{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
- specificato nella struttura puntata da \param{lock}, ritorna un valore nullo
- in caso di successo e $-1$ se il file lock è tenuto da qualcun altro, nel
- qual caso si ha un errore di \errcode{EACCES} o \errcode{EAGAIN}. Questa
- funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
+\item[\constd{F\_SETLK}] richiede o rilascia un \textit{file lock} a seconda
+ di quanto specificato nella struttura puntata dal terzo argomento (sempre di
+ tipo \ctyp{struct flock *}); ritorna un valore nullo in caso di successo e
+ $-1$ se il \textit{file lock} è tenuto da qualcun altro, nel qual caso si ha
+ un errore di \errcode{EACCES} o \errcode{EAGAIN}. Questa funzionalità è
+ trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
\item[\constd{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
imposta \var{errno} a \errcode{EINTR}. Questa funzionalità è trattata in
dettaglio in sez.~\ref{sec:file_posix_lock}.
+\item[\constd{F\_OFD\_GETLK}] analoga di \constd{F\_GETLK} ma per i nuovi
+ \textit{open file descriptor locks} introdotti con il kernel 3.15, richiede
+ un controllo sul \textit{file lock} specificato nella struttura
+ \struct{flock} puntata dal terzo argomento (che pertanto dovrà essere di
+ tipo \ctyp{struct flock *}) sovrascrivendone il contenuto con il risultato,
+ ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Come
+ per i due successivi comandi oltre a \errval{EBADF} se il terzo argomento
+ non è un puntatore valido restituisce l'errore generico
+ \errcode{EFAULT}. Questa funzionalità è trattata in dettaglio in
+ sez.~\ref{sec:open_file_descriptor_locks}.
+
+\item[\constd{F\_OFD\_SETLK}] analoga di \constd{F\_SETLK} ma per i nuovi
+ \textit{open file descriptor locks} introdotti con il kernel 3.15, richiede
+ o rilascia un \textit{file lock} a seconda di quanto specificato nella
+ struttura puntata dal terzo argomento (sempre di tipo \ctyp{struct flock
+ *}); ritorna un valore nullo in caso di successo e $-1$ se il \textit{file
+ lock} è tenuto da qualcun altro, nel qual caso si ha un errore di
+ \errcode{EACCES} o \errcode{EAGAIN}. Questa funzionalità è trattata in
+ dettaglio in sez.~\ref{sec:open_file_descriptor_locks}.
+
+\item[\constd{F\_OFD\_SETLKW}] identica a \const{F\_OFD\_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
+ sez.~\ref{sec:open_file_descriptor_locks}.
+
\item[\constd{F\_GETOWN}] restituisce in caso di successo l'identificatore del
processo o del \textit{process group} (vedi sez.~\ref{sec:sess_proc_group})
- che è preposto alla ricezione del segnale \signal{SIGIO} (o l'eventuale
- segnale alternativo impostato con \const{F\_SETSIG}) per gli eventi
- asincroni associati al file descriptor \param{fd} e del segnale
- \signal{SIGURG} per la notifica dei dati urgenti di un socket (vedi
- sez.~\ref{sec:TCP_urgent_data}). Restituisce $-1$ in caso di errore ed il
- terzo argomento viene ignorato. Non sono previsti errori diversi da
- \errval{EBADF}.
+ che è preposto alla ricezione dei segnali \signal{SIGIO} o \signal{SIGURG};
+ il primo (o l'eventuale segnale alternativo impostato con \const{F\_SETSIG})
+ per gli eventi asincroni associati al file descriptor \param{fd} (vedi
+ sez.~\ref{sec:file_asyncronous_operation}), il secondo per la notifica dei
+ dati urgenti di un socket (vedi sez.~\ref{sec:TCP_urgent_data}). Restituisce
+ $-1$ in caso di errore ed il terzo argomento viene ignorato. Non sono
+ previsti errori diversi da \errval{EBADF}.
Per distinguerlo dal caso in cui il segnale viene inviato a un singolo
processo, nel caso di un \textit{process group} viene restituito un valore
il comportamento del comando può risultare diverso a seconda delle versioni
della \acr{glibc} e del kernel.
-\item[\constd{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
- l'identificatore del processo o del \textit{process group} che riceverà i
- segnali \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
- descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
- caso di errore. Oltre a \errval{EBADF} gli errori possibili sono
- \errcode{ESRCH} se \param{arg} indica un processo o un \textit{process
- group} inesistente.
+\item[\constd{F\_SETOWN}] imposta, con il valore del terzo argomento
+ \param{arg}, l'identificatore del processo o del \textit{process group} che
+ riceverà i segnali \signal{SIGIO} e \signal{SIGURG} per gli eventi asincroni
+ associati al file descriptor \param{fd}. Ritorna un valore nullo in caso di
+ successo o $-1$ in caso di errore. Oltre a \errval{EBADF} gli errori
+ possibili sono \errcode{ESRCH} se \param{arg} indica un processo o un
+ \textit{process group} inesistente.
L'impostazione è soggetta alle stesse restrizioni presenti sulla funzione
\func{kill} (vedi sez.~\ref{sec:sig_kill_raise}), per cui un utente non
valore negativo, il cui valore assoluto corrisponda all'identificatore del
\textit{process group}.
- A partire dal kernel 2.6.12 se si sta operando con i \textit{thread} della
+ A partire dal kernel 2.6.12, se si sta operando con i \textit{thread} della
implementazione nativa di Linux (quella della NTPL, vedi
sez.~\ref{sec:linux_ntpl}) e se si è impostato un segnale specifico con
\const{F\_SETSIG}, un valore positivo di \param{arg} viene interpretato come
indicante un \textit{Thread ID} e non un \textit{Process ID}. Questo
consente di inviare il segnale impostato con \const{F\_SETSIG} ad uno
- specifico \textit{thread}. In genere questo non comporta differenze
- significative per il processi ordinari, in cui non esistono altri
- \textit{thread}, dato che su Linux il \textit{thread} principale, che in tal
- caso è anche l'unico, mantiene un valore del \textit{Thread ID} uguale al
- \ids{PID} del processo. Il problema è però che questo comportamento non si
- applica a \signal{SIGURG}, per il quale \param{arg} viene sempre
- interpretato come l'identificatore di un processo o di un \textit{process
- group}.
-
-\item[\constd{F\_GETOWN\_EX}] legge nella struttura puntata
- dall'argomento \param{owner} l'identificatore del processo, \textit{thread}
- o \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}) che è
- preposto alla ricezione dei segnali \signal{SIGIO} e \signal{SIGURG} per gli
- eventi associati al file descriptor \param{fd}. Ritorna un valore nullo in
- caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF} e da
- \errval{EFAULT} se \param{owner} non è un puntatore valido.
+ specifico \textit{thread}.
+
+ In genere questo non comporta differenze significative per il processi
+ ordinari, in cui non esistono altri \textit{thread}, dato che su Linux il
+ \textit{thread} principale, che in tal caso è anche l'unico, mantiene un
+ valore del \textit{Thread ID} uguale al \ids{PID} del processo. Il problema
+ è però che questo comportamento non si applica a \signal{SIGURG}, per il
+ quale \param{arg} viene sempre interpretato come l'identificatore di un
+ processo o di un \textit{process group}.
+
+\item[\constd{F\_GETOWN\_EX}] legge nella struttura puntata dal terzo
+ argomento (che deve essere di tipo \ctyp{struct f\_owner\_ex *})
+ l'identificatore del processo, \textit{thread} o \textit{process group} che
+ è preposto alla ricezione dei segnali \signal{SIGIO} e \signal{SIGURG} per
+ gli eventi associati al file descriptor \param{fd}. Ritorna un valore nullo
+ in caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF} l'unico
+ altro errore è \errval{EFAULT} se \param{owner} non è un puntatore valido.
Il comando, che è disponibile solo a partire dal kernel 2.6.32, effettua lo
stesso compito di \const{F\_GETOWN} di cui costituisce una evoluzione che
consente di superare i limiti e le ambiguità relative ai valori restituiti
come identificativo. A partire dalla versione 2.11 della \acr{glibc} esso
viene usato dalla libreria per realizzare una versione di \func{fcntl} che
- non presenti i problemi illustrati in precedenza per la versione precedente
- di \const{F\_GETOWN}. Il comando è specifico di Linux ed utilizzabile solo
- se si è definita la macro \macro{\_GNU\_SOURCE}.
-
-\item[\constd{F\_SETOWN\_EX}] imposta con il valore della struttura
- \struct{f\_owner\_ex} puntata \param{owner}, l'identificatore del processo o
- del \textit{process group} che riceverà i segnali \signal{SIGIO} e
- \signal{SIGURG} per gli eventi associati al file
- descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
- caso di errore, con gli stessi errori di \const{F\_SETOWN} più
- \errcode{EINVAL} se il campo \var{type} di \struct{f\_owner\_ex} non indica
- un tipo di identificatore valido.
-
+ non presenti i problemi illustrati in precedenza per \const{F\_GETOWN}. Il
+ comando è specifico di Linux ed utilizzabile solo se si è definita la macro
+ \macro{\_GNU\_SOURCE}.
+
\begin{figure}[!htb]
\footnotesize \centering
\begin{varwidth}[c]{0.5\textwidth}
\label{fig:f_owner_ex}
\end{figure}
+\item[\constd{F\_SETOWN\_EX}] imposta con il valore della struttura puntata
+ dal terzo argomento (che deve essere di tipo \ctyp{struct f\_owner\_ex *})
+ l'identificatore del processo o del \textit{process group} che riceverà i
+ segnali \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
+ descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
+ caso di errore, con gli stessi errori di \const{F\_SETOWN} più
+ \errcode{EINVAL} se il campo \var{type} di \struct{f\_owner\_ex} non indica
+ un tipo di identificatore valido.
+
Come \const{F\_GETOWN\_EX} il comando richiede come terzo argomento il
- puntatore ad una struttura \struct{f\_owner\_ex} la cui definizione è
- riportata in fig.~\ref{fig:f_owner_ex}, in cui il primo campo indica il tipo
- di identificatore il cui valore è specificato nel secondo campo, che assume
- lo stesso significato di \param{arg} per \const{F\_SETOWN}. Per il campo
- \var{type} i soli valori validi sono \constd{F\_OWNER\_TID},
+ puntatore ad una struttura \struct{f\_owner\_ex} (la cui definizione è
+ riportata in fig.~\ref{fig:f_owner_ex}) in cui il campo \var{type} indica il
+ tipo di identificatore che si intende usare, mentre il relativo valore è
+ specificato nel campo \var{pid}, che assume lo stesso significato del terzo
+ argomenti di \const{F\_SETOWN}.
+
+ Per \var{type} i soli valori validi sono \constd{F\_OWNER\_TID},
\constd{F\_OWNER\_PID} e \constd{F\_OWNER\_PGRP}, che indicano
rispettivamente che si intende specificare con \var{pid} un \textit{Tread
ID}, un \textit{Process ID} o un \textit{Process Group ID}. A differenza
di \const{F\_SETOWN} se si specifica un \textit{Tread ID} questo riceverà
sia \signal{SIGIO} (o il segnale impostato con \const{F\_SETSIG}) che
\signal{SIGURG}. Il comando è specifico di Linux, è disponibile solo a
- partire dal kernel 2.6.32, ed è utilizzabile solo se si è definita la macro
+ partire dal kernel 2.6.32 ed è utilizzabile solo se si è definita la macro
\macro{\_GNU\_SOURCE}.
-\item[\constd{F\_GETSIG}] restituisce il valore del segnale inviato dai vari
- meccanismi di I/O asincrono associati al file descriptor \param{fd} (quelli
- trattati in sez.~\ref{sec:file_asyncronous_operation}) in caso di successo o
- $-1$ in caso di errore, il terzo argomento viene ignorato. Non sono previsti
- errori diversi da \errval{EBADF}. Un valore nullo indica che si sta usando
- il segnale predefinito, che è \signal{SIGIO}. Un valore diverso da zero
- indica il segnale che è stato impostato con \const{F\_SETSIG}, che può
- essere anche lo stesso \signal{SIGIO}. Il comando è specifico di Linux ed
- utilizzabile solo se si è definita la macro \macro{\_GNU\_SOURCE}.
+\item[\constd{F\_GETSIG}] restituisce in caso di successo il valore del
+ segnale inviato dai vari meccanismi di I/O asincrono associati al file
+ descriptor \param{fd} (quelli trattati in
+ sez.~\ref{sec:file_asyncronous_operation}) o $-1$ in caso di errore, il
+ terzo argomento viene ignorato. Non sono previsti errori diversi da
+ \errval{EBADF}. Un valore nullo indica che si sta usando il segnale
+ predefinito, che è \signal{SIGIO}. Un valore diverso da zero indica il
+ segnale che è stato impostato con \const{F\_SETSIG}, che può essere anche lo
+ stesso \signal{SIGIO}. Il comando è specifico di Linux ed utilizzabile solo
+ se si è definita la macro \macro{\_GNU\_SOURCE}.
\item[\constd{F\_SETSIG}] imposta il segnale inviato dai vari meccanismi di
I/O asincrono associati al file descriptor \param{fd} (quelli trattati in
L'impostazione 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
+ \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}. Se inoltre si imposta un segnale \textit{real-time} si
solo se si è definita la macro \macro{\_GNU\_SOURCE}. Questa funzionalità è
trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
-\item[\constd{F\_SETLEASE}] imposta o rimuove a seconda del valore
- di \param{arg} un \textit{file lease} sul file descriptor \var{fd} a seconda
- del valore indicato da \param{arg}. Ritorna un valore nullo in caso di
- successo o $-1$ in caso di errore. Oltre a \errval{EBADF} si otterrà
- \errcode{EINVAL} se si è specificato un valore non valido per \param{arg}
- (deve essere usato uno dei valori di tab.~\ref{tab:file_lease_fctnl}),
- \errcode{ENOMEM} se non c'è memoria sufficiente per creare il \textit{file
- lease}, \errcode{EACCES} se non si è il proprietario del file e non si
- hanno i privilegi di amministratore.\footnote{per la precisione occorre la
- capacità \const{CAP\_LEASE}.}
-
- Il supporto il supporto per i \textit{file lease}, che consente ad un
- processo che detiene un \textit{lease} su un file di riceve una notifica
- qualora un altro processo cerchi di eseguire una \func{open} o una
- \func{truncate} su di esso è stato introdotto a partire dai kernel della
- serie 2.4 Il comando è specifico di Linux ed utilizzabile solo se si è
- definita la macro \macro{\_GNU\_SOURCE}. Questa funzionalità è trattata in
- dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
+\item[\constd{F\_SETLEASE}] imposta o rimuove a seconda del valore del terzo
+ argomento \param{arg} un \textit{file lease} sul file descriptor
+ \var{fd}. Ritorna un valore nullo in caso di successo o $-1$ in caso di
+ errore. Oltre a \errval{EBADF} si otterrà \errcode{EINVAL} se si è
+ specificato un valore non valido per \param{arg} (deve essere usato uno dei
+ valori di tab.~\ref{tab:file_lease_fctnl}), \errcode{ENOMEM} se non c'è
+ memoria sufficiente per creare il \textit{file lease}, \errcode{EACCES} se
+ non si è il proprietario del file e non si hanno i privilegi di
+ amministratore (per la precisione occorre la capacità \const{CAP\_LEASE},
+ vedi sez.~\ref{sec:proc_capabilities}).
+
+ Il supporto per i \textit{file lease}, che consente ad un processo che
+ detiene un \textit{lease} su un file di ricevere una notifica qualora un
+ altro processo cerchi di eseguire una \func{open} o una \func{truncate} su
+ di esso, è stato introdotto a partire dai kernel della serie 2.4. Il comando
+ è specifico di Linux ed utilizzabile solo se si è definita la macro
+ \macro{\_GNU\_SOURCE}. Questa funzionalità è trattata in dettaglio in
+ sez.~\ref{sec:file_asyncronous_lease}.
\item[\constd{F\_NOTIFY}] attiva il meccanismo di notifica asincrona per cui
viene riportato al processo chiamante, tramite il segnale \signal{SIGIO} (o
gli errori possibili sono \errcode{EBUSY} se si cerca di ridurre la
dimensione del buffer al di sotto della quantità di dati effettivamente
presenti su di esso ed \errcode{EPERM} se un processo non privilegiato cerca
- di impostare un valore troppo alto. La dimensione minima del buffer è pari
- ad una pagina di memoria, a cui verrà comunque arrotondata ogni dimensione
- inferiore, il valore specificato viene in genere arrotondato per eccesso al
- valore ritenuto più opportuno dal sistema, pertanto una volta eseguita la
- modifica è opportuno rileggere la nuova dimensione con
- \const{F\_GETPIPE\_SZ}. I processi non privilegiati\footnote{per la
- precisione occorre la capacità \const{CAP\_SYS\_RESOURCE}.} non possono
- impostare un valore valore superiore a quello indicato da
- \sysctlfile{fs/pipe-size-max}. Il comando è specifico di Linux, è
+ di impostare un valore troppo alto.
+
+ La dimensione minima del buffer è pari ad una pagina di memoria, a cui verrà
+ comunque arrotondata ogni dimensione inferiore, il valore specificato viene
+ in genere arrotondato per eccesso al valore ritenuto più opportuno dal
+ sistema, pertanto una volta eseguita la modifica è opportuno rileggere la
+ nuova dimensione con \const{F\_GETPIPE\_SZ}.
+
+ I processi non privilegiati (occorre la capacità \const{CAP\_SYS\_RESOURCE})
+ non possono impostare un valore superiore a quello indicato da
+ \sysctlfiled{fs/pipe-max-size}. Il comando è specifico di Linux, è
disponibile solo a partire dal kernel 2.6.35, ed è utilizzabile solo se si è
definita la macro \macro{\_GNU\_SOURCE}.
+\item[\constd{F\_GET\_SEALS}] restituisce in caso di successo l'insieme dei
+ \textit{file seal} presenti su \param{fd}: 0 se non ve ne sono o $-1$ in
+ caso di errore, il terzo argomento viene ignorato. Oltre a \errval{EBADF}
+ se il file non supporta i \textit{file seal} viene restituito un errore di
+ \errval{EINVAL}. Il comando è specifico di Linux, è disponibile solo a
+ partire dal kernel 3.17. Questa funzionalità è trattata in dettaglio in
+ sez.~\ref{sec:file_seal_et_al}.
+
+\item[\constd{F\_ADD\_SEALS}] aggiunge i \textit{file seal} espressi come
+ maschera binaria nell'argomento \param{arg} a quelli presenti su \param{fd},
+ ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Il
+ comando è specifico di Linux, è disponibile solo a partire dal kernel
+ 3.17. Questa funzionalità è trattata in dettaglio in
+ sez.~\ref{sec:file_seal_et_al}.
+
+\item[\constd{F\_GET\_RW\_HINT}] legge il valore dei \textit{read/write hints}
+ associati all'\textit{inode} a cui fa riferimento \param{fd} nella variabile
+ puntata dal terzo argomento che deve essere di tipo \ctyp{uint64\_t
+ *}. Ritorna un valore nullo in caso di successo o $-1$ in caso di
+ errore. Il comando è specifico di Linux, è disponibile solo a partire dal
+ kernel 4.13. Questa funzionalità è trattata in dettaglio in
+ sez.~\ref{sec:file_fadvise}.
+
+\item[\constd{F\_SET\_RW\_HINT}] imposta il valore dei \textit{read/write
+ hints} associati all'\textit{inode} a cui fa riferimento \param{fd}; il
+ valore deve essere fornito nella variabile puntata dal terzo argomento, che
+ deve essere di tipo \ctyp{uint64\_t *}. Ritorna un valore nullo in caso di
+ successo o $-1$ in caso di errore. Il comando è specifico di Linux, è
+ disponibile solo a partire dal kernel 4.13. Questa funzionalità è trattata
+ in dettaglio in sez.~\ref{sec:file_fadvise}.
+
+\item[\constd{F\_GET\_FILE\_RW\_HINT}] legge il valore dei \textit{read/write
+ hints} associati al file descriptor \param{fd} nella variabile puntata dal
+ terzo argomento che deve essere di tipo \ctyp{uint64\_t *}. Ritorna un
+ valore nullo in caso di successo o $-1$ in caso di errore. Il comando è
+ specifico di Linux, è disponibile solo a partire dal kernel 4.13. Questa
+ funzionalità è trattata in dettaglio in sez.~\ref{sec:file_fadvise}.
+
+\item[\constd{F\_SET\_FILE\_RW\_HINT}] legge il valore dei \textit{read/write
+ hints} associati al file descriptor \param{fd}; il valore deve essere
+ fornito nella variabile puntata dal terzo argomento, che deve essere di tipo
+ \ctyp{uint64\_t *}. Ritorna un valore nullo in caso di successo o $-1$ in
+ caso di errore. Il comando è specifico di Linux, è disponibile solo a
+ partire dal kernel 4.13. Questa funzionalità è trattata in dettaglio in
+ sez.~\ref{sec:file_fadvise}.
+
+
\end{basedescript}
+
La maggior parte delle funzionalità controllate dai comandi di \func{fcntl}
sono avanzate e richiedono degli approfondimenti ulteriori, 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} saranno esaminate in sez.~\ref{sec:file_locking}). L'uso
-di questa funzione con i socket verrà trattato in
-sez.~\ref{sec:sock_ctrl_func}.
-
-La gran parte dei comandi di \func{fcntl} (\const{F\_DUPFD}, \const{F\_GETFD},
-\const{F\_SETFD}, \const{F\_GETFL}, \const{F\_SETFL}, \const{F\_GETLK},
-\const{F\_SETLK} e \const{F\_SETLKW}) sono previsti da SVr4 e 4.3BSD e
-standardizzati in POSIX.1-2001 che inoltre prevede gli ulteriori
+sez.~\ref{sec:file_asyncronous_operation}, quelle relative al \textit{file
+ locking} saranno esaminate in sez.~\ref{sec:file_locking}, quelle relative
+ai \textit{file seal} in sez.~\ref{sec:file_seal_et_al} e quelle relative ai
+\textit{read/write hints} in sez.~\ref{sec:file_fadvise}. L'uso di questa
+funzione con i socket verrà trattato in sez.~\ref{sec:sock_ctrl_func}.
+
+La gran parte dei comandi di \func{fcntl} (come \const{F\_DUPFD},
+\const{F\_GETFD}, \const{F\_SETFD}, \const{F\_GETFL}, \const{F\_SETFL},
+\const{F\_GETLK}, \const{F\_SETLK} e \const{F\_SETLKW}) sono previsti da SVr4
+e 4.3BSD e standardizzati in POSIX.1-2001 che inoltre prevede gli ulteriori
\const{F\_GETOWN} e \const{F\_SETOWN}. Pertanto nell'elenco si sono indicate
esplicitamente soltanto le ulteriori richieste in termini delle macro di
funzionalità di sez.~\ref{sec:intro_gcc_glibc_std} soltanto per le
funzionalità inserite in standard successivi o specifiche di Linux.
-
-% \subsection{La funzione \func{ioctl}}
-% \label{sec:file_ioctl}
-
Benché l'interfaccia di gestione dell'I/O sui file di cui abbiamo parlato
finora si sia dimostrata valida anche per l'interazione diretta con le
periferiche attraverso i loro file di dispositivo, consentendo di usare le
Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
di una apposita funzione di sistema, \funcd{ioctl}, come meccanismo generico
-per compiere operazioni specializzate; il suo prototipo è:
+per compiere operazioni specialistiche; il suo prototipo è:
\begin{funcproto}{
\fhead{sys/ioctl.h}
elenco di alcuni esempi di esse è il seguente:
\begin{itemize*}
\item il cambiamento dei font di un terminale.
-\item l'esecuzione di una traccia audio di un CDROM.
+\item l'esecuzione di una traccia audio di un CD.
\item i comandi di avanti veloce e di riavvolgimento di un nastro.
\item il comando di espulsione di un dispositivo rimovibile.
\item l'impostazione della velocità trasmissione di una linea seriale.
\item l'impostazione della frequenza e della durata dei suoni emessi dallo
speaker.
-\item l'impostazione degli attributi dei file su un filesystem
- ext2.\footnote{i comandi \texttt{lsattr} e \texttt{chattr} fanno questo con
- delle \func{ioctl} dedicate, usabili solo su questo filesystem e derivati
- successivi (come ext3).}
+\item l'impostazione degli attributi dei file (vedi
+ sez.~\ref{sec:file_perm_management}) su un filesystem.\footnote{i comandi
+ \texttt{lsattr} e \texttt{chattr} fanno questo con delle \func{ioctl}
+ dedicate, usabili solo sui filesystem che li supportano.}
\end{itemize*}
In generale ogni dispositivo ha un suo insieme di operazioni specifiche
sono definite nel kernel a livello generale, e vengono sempre interpretate per
prime, per cui, come illustrato in \cite{LinDevDri}, eventuali operazioni
specifiche che usino lo stesso valore verrebbero ignorate:
-\begin{basedescript}{\desclabelwidth{2.0cm}}
+\begin{basedescript}{\desclabelwidth{1.8cm}}
\item[\constd{FIOCLEX}] imposta il flag di \textit{close-on-exec} sul file, in
questo caso, essendo usata come operazione logica, \func{ioctl} non richiede
un terzo argomento, il cui eventuale valore viene ignorato.
% TODO trovare qualche posto per la eventuale documentazione delle seguenti
% (bassa/bassissima priorità)
% EXT4_IOC_MOVE_EXT (dal 2.6.31)
+% EXT4_IOC_SHUTDOWN (dal 4.10), XFS_IOC_GOINGDOWN e futura FS_IOC_SHUTDOWN
% ioctl di btrfs, vedi http://lwn.net/Articles/580732/
-% \chapter{}
\section{L'interfaccia standard ANSI C}
\label{sec:files_std_interface}
Queste funzioni di libreria, insieme alle altre funzioni definite dallo
standard (che sono state implementate la prima volta da Ritchie nel 1976 e da
allora sono rimaste sostanzialmente immutate), vengono a costituire il nucleo
-delle \acr{glibc} per la gestione dei file.
+della \acr{glibc} per la gestione dei file.
-Esamineremo in questa sezione le funzioni base dell'interfaccia degli
-\textit{stream}, analoghe a quelle di sez.~\ref{sec:file_unix_interface} per i
-file descriptor. In particolare vedremo come aprire, leggere, scrivere e
+Esamineremo in questa sezione le funzioni base di questa interfaccia che
+chiameremo, per distinguerla dalla precedente ``degli \textit{stream}''. Esse
+sono analoghe a quelle di sez.~\ref{sec:file_unix_interface} per i file
+descriptor, ed in particolare vedremo come aprire, leggere, scrivere e
cambiare la posizione corrente in uno \textit{stream}.
Per rispondere ad esigenze diverse lo standard definisce tre distinte modalità
in cui può essere eseguita la bufferizzazione, delle quali occorre essere ben
consapevoli, specie in caso di lettura e scrittura da dispositivi interattivi:
-\begin{itemize}
+\begin{itemize*}
\item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
caratteri vengono trasmessi direttamente al file non appena possibile
(effettuando immediatamente una \func{write});
quando si preme invio);
\item \textit{fully buffered}: in questo caso i caratteri vengono
trasmessi da e verso il file in blocchi di dimensione opportuna.
-\end{itemize}
+\end{itemize*}
Lo standard ANSI C specifica inoltre che lo \textit{standard output} e lo
\textit{standard input} siano aperti in modalità \textit{fully buffered}
Infine \func{fdopen} viene usata per associare uno \textit{stream} ad un file
descriptor esistente ottenuto tramite una altra funzione (ad esempio con una
\func{open}, una \func{dup}, o una \func{pipe}) e serve quando si vogliono
-usare gli \textit{stream} con file come le fifo o i socket, che non possono
+usare gli \textit{stream} con file come le \textit{fifo} o i socket, che non possono
essere aperti con le funzioni delle librerie standard del C.
\begin{table}[htb]
scrittura.\\
\hline
\texttt{b} & Specifica che il file è binario, non ha alcun effetto. \\
- \texttt{x} & L'apertura fallisce se il file esiste già. \\
+ \texttt{c} & Evita che l'apertura e seguenti letture o scritture diventino
+ un \textit{cancellation point} per i \textit{thread};
+ presente dalla \acr{glibc} 2.3.3. \\
+ \texttt{e} & Apre il file con il flag di \const{O\_CLOEXEC}; presente
+ dalla \acr{glibc} 2.7. \\
+ \texttt{m} & Cerca di accedere al file con \func{mmap} invece
+ che con le funzioni di I/O classiche; presente
+ dalla \acr{glibc} 2.3. \\
+ \texttt{x} & L'apertura fallisce se il file esiste già (ignorato con
+ \func{fdopen}).\\
\hline
\end{tabular}
\caption{Modalità di apertura di uno \textit{stream} dello standard ANSI C
In realtà lo standard ANSI C prevede un totale di 15 possibili valori
diversi per \param{mode}, ma in tab.~\ref{tab:file_fopen_mode} si sono
riportati solo i sei valori effettivi, ad essi può essere aggiunto pure
-il carattere \texttt{b} (come ultimo carattere o nel mezzo agli altri per
+il carattere ``\texttt{b}'' (come ultimo carattere o nel mezzo agli altri per
le stringhe di due caratteri) che in altri sistemi operativi serve a
distinguere i file binari dai file di testo; in un sistema POSIX questa
distinzione non esiste e il valore viene accettato solo per
compatibilità, ma non ha alcun effetto.
-Le \acr{glibc} supportano alcune estensioni, queste devono essere sempre
-indicate dopo aver specificato il \param{mode} con uno dei valori di
-tab.~\ref{tab:file_fopen_mode}. L'uso del carattere \texttt{x} serve per
-evitare di sovrascrivere un file già esistente (è analoga all'uso dell'opzione
-\const{O\_EXCL} in \func{open}): se il file specificato già esiste e si
-aggiunge questo carattere a \param{mode} la \func{fopen} fallisce.
-
-Un'altra estensione serve a supportare la localizzazione, quando si
-aggiunge a \param{mode} una stringa della forma \verb|",ccs=STRING"| il
-valore \verb|STRING| è considerato il nome di una codifica dei caratteri
-e \func{fopen} marca il file per l'uso dei caratteri estesi e abilita le
-opportune funzioni di conversione in lettura e scrittura.
+La \acr{glibc} supporta alcune estensioni, queste devono essere sempre
+indicate dopo aver specificato il \param{mode} con uno dei valori della
+seconda sezione di tab.~\ref{tab:file_fopen_mode}. Ad esempio l'uso del
+carattere ``\texttt{e}'' serve ad impostare il \textit{close-on-exec} sul file
+(è analoga all'uso del flag \const{O\_CLOEXEC} in \func{open}), ``\texttt{x}''
+serve per evitare di sovrascrivere un file già esistente (è analoga all'uso
+del flag \const{O\_EXCL} in \func{open}): se il file specificato già esiste e
+si aggiunge questo carattere a \param{mode} la \func{fopen} fallisce.
+
+Altri due valori hanno usi specialistici, con ``\texttt{m}'' si chiede di
+usare il \textit{memory mapping} per l'accesso al file (tratteremo i file
+mappati in memoria in sez.~\ref{sec:file_memory_map}), ma la funzionalità è al
+momento disponibile solo per i file aperti in sola lettura. Con ``\texttt{c}''
+infine si richiede che l'apertura, e le successive operazioni di lettura e
+scrittura, non diventino un \textit{cancellation point} per i \textit{thread}
+(tratteremo l'argomento in sez.~\ref{sec:xxx_thread}).
+
+Un'altra estensione serve a supportare la localizzazione, quando si aggiunge a
+\param{mode} una stringa della forma \verb|",ccs=STRING"| (che deve essere
+sempre in coda a tutte le altre) il valore \verb|STRING| è considerato il nome
+di una codifica dei caratteri e \func{fopen} marca il file per l'uso dei
+caratteri estesi e abilita le opportune funzioni di conversione in lettura e
+scrittura.
Nel caso si usi \func{fdopen} i valori specificati da \param{mode} devono
essere compatibili con quelli con cui il file descriptor è stato aperto.
tutti i dati presenti nei buffer di uscita e scarta tutti i dati in ingresso;
se era stato allocato un buffer per lo \textit{stream} questo verrà
rilasciato. La funzione effettua lo scarico solo per i dati presenti nei
-buffer in \textit{user space} usati dalle \acr{glibc}; se si vuole essere
+buffer in \textit{user space} usati dalla \acr{glibc}; se si vuole essere
sicuri che il kernel forzi la scrittura su disco occorrerà effettuare una
\func{sync} (vedi sez.~\ref{sec:file_sync}).
-Linux supporta anche una altra funzione, \funcd{fcloseall}, come estensione
-GNU implementata dalle \acr{glibc}, accessibile avendo definito
+Linux supporta anche un'altra funzione, \funcd{fcloseall}, come estensione
+GNU implementata dalla \acr{glibc}, accessibile avendo definito
\macro{\_GNU\_SOURCE}, il suo prototipo è:
\begin{funcproto}{
Una delle caratteristiche più utili dell'interfaccia degli \textit{stream} è
la ricchezza delle funzioni disponibili per le operazioni di lettura e
-scrittura sui file. Sono infatti previste ben tre diverse modalità modalità di
+scrittura sui file. Sono infatti previste ben tre diverse modalità di
input/output non formattato:
-\begin{itemize}
-\item\textsl{binario} in cui si leggono e scrivono blocchi di dati di
- dimensione arbitraria, (analogo della modalità ordinaria dell'I/O sui file
- descriptor), trattato in sez.~\ref{sec:file_binary_io}.
-\item\textsl{a caratteri} in cui si legge e scrive un carattere alla volta,
- con la bufferizzazione che viene gestita automaticamente dalla libreria,
- trattato in sez.~\ref{sec:file_char_io}.
-\item\textsl{di linea} in cui si legge e scrive una linea alla volta,
- (terminata dal carattere di newline \verb|'\n'|), trattato in
- sez.~\ref{sec:file_line_io}.
-\end{itemize}
-a cui si aggiunge la modalità di input/output formattato, trattato in
-sez.~\ref{sec:file_formatted_io}.
-
-Ognuna di queste modalità utilizza per l'I/O delle funzioni specifiche che
-vedremo nelle sezioni citate, affronteremo qui tutte gli argomenti e le
-funzioni che si applicano in generale a tutte le modalità di I/O.
-
-A differenza di quanto avviene con l'interfaccia dei file descriptor, con gli
-\textit{stream} il raggiungimento della fine del file viene considerato un
-errore, e viene notificato come tale dai valori di uscita delle varie
-funzioni. Nella maggior parte dei casi questo avviene con la restituzione del
-valore intero (di tipo \ctyp{int}) \val{EOF} definito anch'esso nell'header
+\begin{itemize*}
+\item\textsl{Input/Output binario}, una modalità in cui si leggono e scrivono
+ blocchi di dati di dimensione arbitraria; è l'analogo della modalità
+ ordinaria dell'input/output sui file descriptor vista in
+ sez.~\ref{sec:file_read} e \ref{sec:file_write}.
+\item\textsl{Input/Output a caratteri}, una modalità in cui si legge e scrive
+ un singolo carattere alla volta, anche in questo caso la bufferizzazione
+ viene gestita automaticamente dalla libreria;
+\item\textsl{Input/Output di linea}, una modalità in cui si legge e scrive una
+ linea di testo alla volta, in questa modalità si intende per linea una
+ sequenza di caratteri terminata dal carattere di \textit{newline}
+ (\verb|'\n'|);
+\end{itemize*}
+
+A queste tre modalità si aggiunge poi la modalità di input/output formattato
+che tratteremo in sez.~\ref{sec:file_unformatted_io}. Ognuna di queste
+modalità utilizza per l'I/O delle funzioni specifiche che vedremo più avanti,
+affronteremo qui invece gli argomenti e le funzioni che si applicano in
+generale a tutte queste diverse modalità di I/O.
+
+Una prima caratteristica specifica è che differenza di quanto avviene con
+l'interfaccia dei file descriptor, con gli \textit{stream} il raggiungimento
+della fine del file viene considerato un errore, che viene notificato come
+tale dai valori di uscita delle varie funzioni.
+
+In vari casi questo avviene con la restituzione di uno specifico
+valore intero (di tipo \ctyp{int}) definito come \val{EOF} nell'header
\headfile{stdlib.h}. La costante deve essere negativa perché in molte funzioni
-un valore positivo indica la quantità di dati scritti, le \acr{glibc} usano il
-valore $-1$, ma altre implementazioni possono avere valori diversi.
+un valore positivo indica la quantità di dati scritti e ci potrebbe essere
+sovrapposizione, la \acr{glibc} usa il valore $-1$, ma altre implementazioni
+possono avere valori diversi.
Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
-libreria che si appoggiano a delle \textit{system call}, esse non impostano
-direttamente la variabile \var{errno}, che mantiene sempre il valore impostato
-dalla \textit{system call} invocata internamente che ha riportato l'errore.
+libreria realizzate usando delle \textit{system call}, esse non modificano mai
+direttamente la variabile \var{errno}, che in caso di errore mantiene sempre
+il valore impostato dalla \textit{system call} sottostante che lo ha
+riportato.
Siccome la condizione di \textit{end-of-file} è anch'essa segnalata come
-errore, nasce il problema di come distinguerla da un errore effettivo; basarsi
-solo sul valore di ritorno della funzione e controllare il valore di
-\var{errno} infatti non basta, dato che quest'ultimo potrebbe essere stato
-impostato in una altra occasione, (si veda sez.~\ref{sec:sys_errno} per i
-dettagli del funzionamento di \var{errno}).
+errore, nasce il problema di come distinguerla; basarsi solo sul valore di
+ritorno della funzione e controllare il valore di \var{errno} infatti non
+basta, dato che quest'ultimo potrebbe essere stato impostato in una altra
+occasione, (si veda sez.~\ref{sec:sys_errno} per i dettagli del funzionamento
+di \var{errno}).
Per questo motivo tutte le implementazioni delle librerie standard mantengono
per ogni \textit{stream} almeno due flag all'interno dell'oggetto \type{FILE},
punto prestabilito, sempre che l'operazione di riposizionamento sia supportata
dal file sottostante lo \textit{stream}, nel caso cioè in cui si ha a che fare
con quello che viene detto un file ad \textsl{accesso casuale}. Dato che in un
-sistema Unix esistono vari tipi di file, come le fifo ed i file di dispositivo
-(ad esempio i terminali), non è scontato che questo sia vero in generale, pur
-essendolo sempre nel caso di file di dati.
+sistema Unix esistono vari tipi di file, come le \textit{fifo} ed i file di
+dispositivo (ad esempio i terminali), non è scontato che questo sia vero in
+generale, pur essendolo sempre nel caso di file di dati.
Con Linux ed in generale in ogni sistema unix-like la posizione nel file, come
abbiamo già visto in sez.~\ref{sec:file_lseek}, è espressa da un intero
% TODO: mettere prototipi espliciti fseeko e ftello o menzione?
-
-\subsection{Input/output binario}
-\label{sec:file_binary_io}
+\subsection{Input/output non formattato}
+\label{sec:file_unformatted_io}
La prima modalità di input/output non formattato ricalca quella della
interfaccia dei file descriptor, e provvede semplicemente la scrittura e la
\begin{funcproto}{
\fhead{stdio.h}
\fdecl{size\_t fread(void *ptr, size\_t size, size\_t nmemb, FILE *stream)}
-\fdesc{Legge i dati da uno \textit{stream}.}
+\fdesc{Legge i dati da uno \textit{stream} ad un buffer.}
\fdecl{size\_t fwrite(const void *ptr, size\_t size, size\_t nmemb,
FILE *stream)}
-\fdesc{Scrive i dati su uno \textit{stream}.}
+\fdesc{Scrive i dati da un buffer su uno \textit{stream}.}
}
{Le funzioni ritornano il numero di elementi letti o scritti, in caso di
ordinamento dei bit o il formato delle variabili in floating point.
Per questo motivo quando si usa l'input/output binario occorre sempre prendere
-le opportune precauzioni (in genere usare un formato di più alto livello che
-permetta di recuperare l'informazione completa), per assicurarsi che versioni
-diverse del programma siano in grado di rileggere i dati tenendo conto delle
+le opportune precauzioni come usare un formato di più alto livello che
+permetta di recuperare l'informazione completa, per assicurarsi che versioni
+diverse del programma siano in grado di rileggere i dati, tenendo conto delle
eventuali differenze.
-Le \acr{glibc} definiscono altre due funzioni per l'I/O binario,
-\funcd{fread\_unlocked} e \funcd{fwrite\_unlocked} che evitano il lock
-implicito dello \textit{stream}, usato per dalla librerie per la gestione
-delle applicazioni \textit{multi-thread} (si veda
-sez.~\ref{sec:file_stream_thread} per i dettagli), i loro prototipi sono:
-
-\begin{funcproto}{
-\fhead{stdio.h}
-\fdecl{size\_t fread\_unlocked(void *ptr, size\_t size, size\_t
- nmemb, FILE *stream)}
-\fdecl{size\_t fwrite\_unlocked(const void *ptr, size\_t size,
- size\_t nmemb, FILE *stream)}
-\fdesc{Leggono o scrivono dati su uno \textit{stream} senza acquisire il lock
- implicito sullo stesso.}
-}
-
-{Le funzioni ritornano gli stessi valori delle precedenti \func{fread} e
- \func{fwrite}.}
-\end{funcproto}
-
-% TODO: trattare in generale le varie *_unlocked
-
-
-\subsection{Input/output a caratteri}
-\label{sec:file_char_io}
-
-La seconda modalità di input/output è quella a caratteri, in cui si
-trasferisce un carattere alla volta. Le funzioni per la lettura a
+La seconda modalità di input/output non formattato è quella a caratteri, in
+cui si trasferisce un carattere alla volta. Le funzioni per la lettura a
caratteri sono tre, \funcd{fgetc}, \funcd{getc} e \funcd{getchar}, ed i
rispettivi prototipi sono:
ritorno è sempre un intero; in caso di errore o fine del file il valore di
ritorno è \val{EOF}.
-Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} le \acr{glibc}
-provvedono come estensione, per ciascuna delle funzioni precedenti,
+Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} la \acr{glibc}
+provvede come estensione, per ciascuna delle funzioni precedenti,
un'ulteriore funzione, il cui nome è ottenuto aggiungendo un
\code{\_unlocked}, che esegue esattamente le stesse operazioni, evitando però
il lock implicito dello \textit{stream}.
operazioni di riposizionamento (vedi sez.~\ref{sec:file_io}) i caratteri
rimandati indietro vengono scartati.
-
-\subsection{Input/output di linea}
-\label{sec:file_line_io}
-
La terza ed ultima modalità di input/output non formattato è quella di linea,
in cui si legge o si scrive una riga alla volta. Questa è la modalità usata
normalmente per l'I/O da terminale, ed è anche quella che presenta le
caratteri massimo, terminatore della stringa, \textit{newline}) è espresso in
termini di caratteri estesi anziché di normali caratteri ASCII.
-Come per l'I/O binario e quello a caratteri, anche per l'I/O di linea le
-\acr{glibc} supportano una serie di altre funzioni, estensioni di tutte quelle
-illustrate finora (eccetto \func{gets} e \func{puts}), che eseguono
-esattamente le stesse operazioni delle loro equivalenti, evitando però il lock
-implicito dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}). Come
-per le altre forma di I/O, dette funzioni hanno lo stesso nome della loro
-analoga normale, con l'aggiunta dell'estensione \code{\_unlocked}.
-
Come abbiamo visto, le funzioni di lettura per l'input/output di linea
previste dallo standard ANSI C presentano svariati inconvenienti. Benché
\func{fgets} non abbia i gravissimi problemi di \func{gets}, può comunque dare
complicazione ulteriore della logica del programma. Lo stesso dicasi quando si
deve gestire il caso di stringa che eccede le dimensioni del buffer.
-Per questo motivo le \acr{glibc} prevedono, come estensione GNU, due nuove
+Per questo motivo la \acr{glibc} prevede, come estensione GNU, due nuove
funzioni per la gestione dell'input/output di linea, il cui uso permette di
risolvere questi problemi. L'uso di queste funzioni deve essere attivato
definendo la macro \macro{\_GNU\_SOURCE} prima di includere
Essa prende come primo argomento l'indirizzo del puntatore al buffer su cui si
vuole copiare la linea. Quest'ultimo \emph{deve} essere stato allocato in
-precedenza con una \func{malloc}, non si può cioè passare come argomento primo
+precedenza con una \func{malloc}: non si può cioè passare come argomento primo
argomento l'indirizzo di un puntatore ad una variabile locale. Come secondo
argomento la funzione vuole l'indirizzo della variabile contenente le
-dimensioni del buffer suddetto.
+dimensioni del suddetto buffer.
Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova
\label{tab:file_format_flag}
\end{table}
-Dettagli ulteriori sulle varie opzioni di stampa e su tutte le casistiche
-dettagliate dei vari formati possono essere trovati nella pagina di manuale di
-\func{printf} e nella documentazione delle \acr{glibc}.
+Dettagli ulteriori sulle varie opzioni di stampa e su tutte le casistiche dei
+vari formati possono essere trovati nella pagina di manuale di \func{printf} e
+nella documentazione della \acr{glibc}.
\begin{table}[htb]
\centering
valore negativo per un errore.}
\end{funcproto}
-Con queste funzioni diventa possibile selezionare gli argomenti che si
-vogliono passare ad una funzione di stampa, passando direttamente la lista
-tramite l'argomento \param{ap}. Per poter far questo ovviamente la lista
-variabile degli argomenti dovrà essere opportunamente trattata (l'argomento è
-esaminato in sez.~\ref{sec:proc_variadic}), e dopo l'esecuzione della funzione
-l'argomento \param{ap} non sarà più utilizzabile (in generale dovrebbe essere
-eseguito un \code{va\_end(ap)} ma in Linux questo non è necessario).
+Con queste funzioni è possibile selezionare gli argomenti da passare ad una
+funzione di stampa indicando direttamente la lista tramite l'argomento
+\param{ap}. Per poter far questo ovviamente la lista variabile degli argomenti
+dovrà essere trattata come visto in sez.~\ref{sec:proc_variadic}, e dopo
+l'esecuzione della funzione l'argomento \param{ap} non sarà più utilizzabile
+(in generale dovrebbe essere eseguito un \code{va\_end(ap)} ma in Linux questo
+non è necessario).
Come per \func{sprintf} anche per \func{vsprintf} esiste una analoga
\funcd{vsnprintf} che pone un limite sul numero di caratteri che vengono
\textit{stream}. Altre estensioni permettono di scrivere con caratteri
estesi. Anche queste funzioni, il cui nome è generato dalle precedenti
funzioni aggiungendo una \texttt{w} davanti a \texttt{print}, sono trattate in
-dettaglio nella documentazione delle \acr{glibc}.
+dettaglio nella documentazione della \acr{glibc}.
In corrispondenza alla famiglia di funzioni \func{printf} che si usano per
l'output formattato, l'input formattato viene eseguito con le funzioni della
\end{funcproto}
Le funzioni eseguono una scansione della rispettiva fonte di input cercando
-una corrispondenza di quanto letto con il formato dei dati specificato
-da \param{format}, ed effettua le relative conversioni memorizzando il
+una corrispondenza di quanto letto con il formato dei dati specificato da
+\param{format}, ed effettuano le relative conversioni memorizzando il
risultato negli argomenti seguenti, il cui numero è variabile e dipende dal
valore di \param{format}. Come per le analoghe funzioni di scrittura esistono
le relative \funcm{vscanf}, \funcm{vfscanf} e \funcm{vsscanf} che usano un
qualunque di caratteri di separazione (che possono essere spazi, tabulatori,
virgole ecc.), mentre caratteri diversi richiedono una corrispondenza
esatta. Le direttive di conversione sono analoghe a quelle di \func{printf} e
-si trovano descritte in dettaglio nelle pagine di manuale e nel manuale delle
+si trovano descritte in dettaglio nelle pagine di manuale e nel manuale della
\acr{glibc}.
Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli
In questo modo diventa possibile usare direttamente \func{fcntl} sul file
descriptor sottostante, ma anche se questo permette di accedere agli attributi
del file descriptor sottostante lo \textit{stream}, non ci dà nessuna
-informazione riguardo alle proprietà dello \textit{stream} medesimo. Le
-\acr{glibc} però supportano alcune estensioni derivate da Solaris, che
+informazione riguardo alle proprietà dello \textit{stream} medesimo. La
+\acr{glibc} però supporta alcune estensioni derivate da Solaris, che
permettono di ottenere informazioni utili relative allo \textit{stream}.
Ad esempio in certi casi può essere necessario sapere se un certo
specifichi la modalità non bufferizzata i valori di \param{buf} e \param{size}
vengono sempre ignorati.
-Oltre a \func{setvbuf} le \acr{glibc} definiscono altre tre funzioni per la
+Oltre a \func{setvbuf} la \acr{glibc} definisce altre tre funzioni per la
gestione della bufferizzazione di uno \textit{stream}: \funcd{setbuf},
\funcd{setbuffer} e \funcd{setlinebuf}, i rispettivi prototipi sono:
vecchie librerie BSD, pertanto non è il caso di usarle se non per la
portabilità su vecchi sistemi.
-Infine le \acr{glibc} provvedono le funzioni non standard, anche queste
+Infine la \acr{glibc} provvede le funzioni non standard, anche queste
originarie di Solaris, \funcd{\_\_flbf} e \funcd{\_\_fbufsize} che permettono
di leggere le proprietà di bufferizzazione di uno \textit{stream}; i cui
prototipi sono:
\func{write}.}
\end{funcproto}
-\noindent anche di questa funzione esiste una analoga \func{fflush\_unlocked}
-(accessibile definendo \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE} o
-\macro{\_GNU\_SOURCE}) che non effettua il blocco dello \textit{stream}.
-
-% TODO aggiungere prototipo \func{fflush\_unlocked}?
-
Se \param{stream} è \val{NULL} lo scarico dei dati è forzato per tutti gli
\textit{stream} aperti. Esistono però circostanze, ad esempio quando si vuole
essere sicuri che sia stato eseguito tutto l'output su terminale, in cui serve
poter effettuare lo scarico dei dati solo per gli \textit{stream} in modalità
-\textit{line buffered}. Per fare questo le \acr{glibc} supportano una
+\textit{line buffered}. Per fare questo la \acr{glibc} supporta una
estensione di Solaris, la funzione \funcd{\_flushlbf}, il cui prototipo è:
\begin{funcproto}{
\subsection{Gli \textit{stream} e i \textit{thread}}
\label{sec:file_stream_thread}
-\itindbeg{thread}
Gli \textit{stream} possono essere usati in applicazioni \textit{multi-thread}
allo stesso modo in cui sono usati nelle applicazioni normali, ma si deve
tutti i programmi che non usano i \textit{thread}), tutta la procedura può
comportare dei costi pesanti in termini di prestazioni.
-Per questo motivo abbiamo visto come alle usuali funzioni di I/O non
-formattato siano associate delle versioni \code{\_unlocked} (alcune previste
-dallo stesso standard POSIX, altre aggiunte come estensioni dalle \acr{glibc})
-che possono essere usate quando il locking non serve\footnote{in certi casi
- dette funzioni possono essere usate, visto che sono molto più efficienti,
- anche in caso di necessità di locking, una volta che questo sia stato
- acquisito manualmente.} con prestazioni molto più elevate, dato che spesso
-queste versioni (come accade per \func{getc} e \func{putc}) sono realizzate
-come macro.
+Per questo motivo alle usuali funzioni di I/O non formattato sono associate
+delle ulteriori versioni, caratterizzate dall'aggiunta del suffisso
+\code{\_unlocked}, che possono essere usate quando il locking non
+serve\footnote{in certi casi dette funzioni possono essere usate, visto che
+ sono molto più efficienti, anche in caso di necessità di locking, una volta
+ che questo sia stato acquisito manualmente.} con prestazioni molto più
+elevate, dato che spesso queste versioni (come accade per \func{getc} e
+\func{putc}) sono realizzate come macro.
La sostituzione di tutte le funzioni di I/O con le relative versioni
\code{\_unlocked} in un programma che non usa i \textit{thread} è però un
-lavoro abbastanza noioso. Per questo motivo le \acr{glibc} forniscono al
+lavoro abbastanza noioso. Per questo motivo la \acr{glibc} fornisce al
programmatore pigro un'altra via, anche questa mutuata da estensioni
introdotte in Solaris, da poter utilizzare per disabilitare in blocco il
locking degli \textit{stream}: l'uso della funzione \funcd{\_\_fsetlocking},
% TODO trattare \func{clearerr\_unlocked}
-\itindend{thread}
-
+Per tutte le funzioni che abbiamo trattato in
+sez.~\ref{sec:files_std_interface} che eseguono I/O sugli \textit{stream}
+esiste una versione ``\texttt{\_unlocked}'',\footnote{non ne esistono per
+ funzioni di informazione come \func{ftell} dato che queste non hanno bisogno
+ di un blocco, l'elenco completo delle funzioni ``\texttt{\_unlocked}''
+ comunque è disponibile nella pagina di manuale delle stesse, accessibile con
+ \texttt{man unlocked\_stdio}. } ma nello standard POSIX sono previste solo
+\funcm{getc\_unlocked}, \funcm{getchar\_unlocked}, \funcm{putc\_unlocked} e
+\funcm{putchar\_unlocked}, tutte le altre pur essendo state aggiunte come
+estensioni dalla \acr{glibc}, non sono standard, anche se sono presenti anche
+su altri sistemi unix; in generale comuqnue l'uso di queste funzioni è
+sconsigliato e non le tratteremo esplicitamente.
%%% Local Variables:
% LocalWords: FIONREAD epoll FIOQSIZE side effects SAFE BYCALLER QUERY EACCES
% LocalWords: EBUSY OpenBSD syncfs futimes timespec only init ESRCH kill NTPL
% LocalWords: ENXIO NONBLOCK WRONLY EPERM NOATIME ETXTBSY EWOULDBLOCK PGRP SZ
-% LocalWords: EFAULT capabilities GETPIPE SETPIPE RESOURCE
+% LocalWords: EFAULT capabilities GETPIPE SETPIPE RESOURCE NFSv InitFile stx
+% LocalWords: Documentation Urlich Drepper futimesat times FullWrite major
+% LocalWords: futimens fs Tread TMPFILE EDQUOT extN Minix UDF XFS mask all'
+% LocalWords: shmem Btrfs ubifs tmpfile fchmod fchown fsetxattr fchdir PF
+% LocalWords: fstatfs SIGTTIN EDESTADDRREQ datagram connect seal pag l'I INO
+% LocalWords: dirty execveat execve scandirat statx AUTOMOUNT automount DAC
+% LocalWords: wrapper EMPTY olddirfd oldpath newdirfd newpath capability ino
+% LocalWords: SEARCH flink choot oldirfd NOREPLACE EXCHANGE WHITEOUT union
+% LocalWords: renamat syscall whiteout overlay filesytem Live nell' sull'
+% LocalWords: statbuf statxbuf IFMT nlink atime mtime fexecve argv envp GET
+% LocalWords: blocks STATS btime RESERVED ctime ATTR dev ENOSYS locks SEALS
+% LocalWords: timestamp attributes COMPRESSED immutable NODUMP HINT hints
+% LocalWords: dump ENCRYPTED rdev all'I dell'I uint cancellation mmap
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+
+% LocalWords: mapping
projects / gapil.git / blobdiff