From 3cb4bde1cb050b006f1fa56e4e758df1f95bb2c4 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Mon, 30 Jan 2012 01:06:20 +0000 Subject: [PATCH] Revisione di open. --- fileio.tex | 471 ++++++++++++++++++++++++++++------------------------- 1 file changed, 248 insertions(+), 223 deletions(-) diff --git a/fileio.tex b/fileio.tex index f7bfdec..9dfa301 100644 --- a/fileio.tex +++ b/fileio.tex @@ -9,7 +9,7 @@ %% License". %% -\chapter{La gestione dei contenuti dei file} +\chapter{La gestione dell'I/O su file} \label{cha:file_IO_interface} @@ -70,27 +70,27 @@ kernel gestisce l'interazione fra processi e file. Abbiamo già accennato in sez.~\ref{sec:proc_hierarchy} come il kernel mantenga un elenco di tutti processi nella cosiddetta \itindex{process~table} \textit{process table}. Lo stesso, come accennato in sez.~\ref{sec:file_vfs_work}, vale anche per tutti i -file che sono stati aperti, il cui elenco viene mantenuto nella cosiddetta +file aperti, il cui elenco viene mantenuto nella cosiddetta \itindex{file~table} \textit{file table}. La \itindex{process~table} \textit{process table} è una tabella che contiene una voce per ciascun processo attivo nel sistema. Ciascuna voce è costituita -da una struttura di tipo \kstruct{task\_struct} nella quale sono raccolte -tutte le informazioni relative al processo, fra queste informazioni c'è anche -il puntatore ad una ulteriore struttura di tipo +dal puntatore a una struttura di tipo \kstruct{task\_struct} nella quale sono +raccolte tutte le informazioni relative al processo, fra queste informazioni +c'è anche il puntatore ad una ulteriore struttura di tipo \kstruct{files\_struct},\footnote{la definizione corrente di questa struttura si trova nel file \texttt{include/linux/fdtable.h} dei sorgenti del kernel, quella mostrata in fig.~\ref{fig:file_proc_file} è una versione pesantemente - semplificata.} in cui sono contenute le informazioni relative ai file che il -processo ha aperto. + semplificata.} che contiene le informazioni relative ai file che il processo +ha aperto. -La \itindex{file~table} \textit{file table} è invece una tabella che contiene -una voce per ciascun file che è stato aperto nel sistema. Come accennato in +La \itindex{file~table} \textit{file table} è una tabella che contiene una +voce per ciascun file che è stato aperto nel sistema. Come accennato in sez.~\ref{sec:file_vfs_work} per ogni file aperto viene allocata una struttura \kstruct{file} e la \textit{file table} è costituita da un elenco di puntatori -a ciascuna di queste strutture, che come illustrato in -fig.~\ref{fig:kstruct_file}, contengono le informazioni necessario per la -gestione dei contenuti del file, fra cui: +a ciascuna di queste strutture, che, come illustrato in +fig.~\ref{fig:kstruct_file}, contengono le informazioni necessarie per la +gestione dei file, ed in particolare: \begin{itemize*} \item lo stato del file nel campo \var{f\_flags}. \item la posizione corrente nel file, il cosiddetto \textit{offset}, nel campo @@ -107,7 +107,7 @@ gestione dei contenuti del file, fra cui: \begin{figure}[!htb] \centering - \includegraphics[width=13cm]{img/procfile} + \includegraphics[width=12cm]{img/procfile} \caption{Schema della architettura dell'accesso ai file attraverso l'interfaccia dei \textit{file descriptor}.} \label{fig:file_proc_file} @@ -144,23 +144,24 @@ Il meccanismo dell'apertura dei file prevede che venga sempre fornito il primo vengono assegnati in successione tutte le volte che si apre un nuovo file, posto che non ne sia stato chiuso nessuno in precedenza. -In tutti i sistemi unix-like esiste una convenzione generale per cui ogni +In tutti i sistemi unix-like esiste poi una convenzione generale per cui ogni processo viene lanciato dalla shell con almeno tre file aperti. Questi, per quanto appena detto, avranno come \itindex{file~descriptor} \textit{file descriptor} i valori 0, 1 e 2. Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe portare a gravi problemi di interoperabilità. -Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè -il file da cui un processo si aspetta di ricevere i dati in ingresso. Il -secondo file è il cosiddetto \textit{standard output}, cioè quello su cui ci -si aspetta debbano essere inviati i dati in uscita. Il terzo è lo -\textit{standard error}, su cui viene inviata l'uscita relativa agli errori. -Nel caso della shell tutti questi file sono associati al terminale di -controllo, e corrispondono quindi alla lettura della tastiera per l'ingresso e -alla scrittura sul terminale per l'uscita. Lo standard POSIX.1 provvede, al -posto dei valori numerici, tre costanti simboliche, definite in -tab.~\ref{tab:file_std_files}. +Il primo file è sempre associato al cosiddetto \itindex{standard~input} +\textit{standard input}, è cioè il file da cui un processo si aspetta di dover +leggere i dati in ingresso. Il secondo file è il cosiddetto +\itindex{standard~output} \textit{standard output}, cioè quello su cui ci si +aspetta di dover scrivere i dati in uscita. Il terzo è lo +\itindex{standard~error} \textit{standard error}, su cui vengono scritti i +dati relativi agli errori. Nel caso della shell tutti questi file sono +associati al terminale di controllo, e corrispondono quindi alla lettura della +tastiera per l'ingresso e alla scrittura sul terminale per l'uscita. Lo +standard POSIX.1 provvede, al posto dei valori numerici, tre costanti +simboliche, definite in tab.~\ref{tab:file_std_files}. \begin{table}[htb] \centering @@ -186,14 +187,15 @@ tab.~\ref{tab:file_std_files}. In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa rispetto a quella usuale della shell, in cui tutti e tre questi file fanno riferimento al terminale su cui si opera. Nell'esempio invece viene illustrata -la situazione di un programma in cui lo \textit{standard input} è associato ad -un certo file mentre lo \textit{standard output} e lo \textit{standard error} -sono entrambi associati ad un altro file. - -Si noti come questi ultimi, pur utilizzando strutture \kstruct{file} diverse, -essendo il file che è stato aperto lo stesso, fanno a loro volta riferimento -allo stesso \itindex{inode} \textit{inode}. Questo è quello che avviene -normalmente quando si apre più volte lo stesso file. +la situazione di un programma in cui lo \itindex{standard~input} +\textit{standard input} è associato ad un file mentre lo +\itindex{standard~output} \textit{standard output} e lo +\itindex{standard~error} \textit{standard error} sono associati ad un altro +file. Si noti poi come per questi ultimi le strutture \kstruct{file} nella +\itindex{file~table} \textit{file table}, pur essendo distinte, fanno +riferimento allo stesso \itindex{inode} \textit{inode}, dato che il file che è +stato aperto lo stesso. Questo è quello che avviene normalmente quando si apre +più volte lo stesso file. Si ritrova quindi anche con le voci della \itindex{file~table} \textit{file table} una situazione analoga di quella delle voci di una directory, con la @@ -217,13 +219,12 @@ sez.~\ref{sec:sys_limits}). \subsection{Apertura e creazione di un file} \label{sec:file_open} -La funzione di sistema \funcd{open} è la funzione fondamentale -dell'interfaccia di gestione dei file su Unix, ed è quella che dato un -\textit{pathname} consente di ottenere un file descriptor ``\textsl{aprendo}'' -il file corrispondente,\footnote{è questa funzione che alloca la struttura - \kstruct{file}, la inserisce nella \itindex{file~table} \textit{file table} - e crea il riferimento nella \kstruct{files\_struct} del processo.} il suo -prototipo è: +La funzione di sistema \funcd{open} è la principale funzione dell'interfaccia +di gestione dei file, quella che dato un \textit{pathname} consente di +ottenere un file descriptor ``\textsl{aprendo}'' il file +corrispondente,\footnote{è \func{open} che alloca \kstruct{file}, la inserisce + nella \itindex{file~table} \textit{file table} e crea il riferimento nella + \kstruct{files\_struct} del processo.} il suo prototipo è: \begin{funcproto}{ \fhead{sys/types.h} @@ -239,207 +240,231 @@ prototipo è: errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EEXIST}] \param{pathname} esiste e si è specificato - \const{O\_CREAT} e \const{O\_EXCL}. + \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. + 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{ELOOP}] si sono incontrati troppi collegamenti simbolici nel + risolvere \param{pathname} o si è indicato \const{O\_NOFOLLOW} e + \param{pathname} è un collegamento simbolico. + \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. \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e \param{pathname} non è una directory. \item[\errcode{ENXIO}] si sono impostati \const{O\_NOBLOCK} 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. - \item[\errcode{ENODEV}] \param{pathname} si riferisce a un file di - dispositivo che non esiste. + \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 di un programma in esecuzione. - \item[\errcode{ELOOP}] si sono incontrati troppi link simbolici nel - risolvere il \textit{pathname} o si è indicato \const{O\_NOFOLLOW} e - \param{pathname} è un link simbolico. + \item[\errcode{EWOULDBLOCK}] la funzione si sarebbe bloccata ma si è + richiesto \const{O\_NOBLOCK}. \end{errlist} - ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOENT}, - \errval{EROFS}, \errval{EFAULT}, \errval{ENOSPC}, \errval{ENOMEM}, - \errval{EMFILE} e \errval{ENFILE} nel loro significato generico.} + ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EMFILE}, + \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM}, \errval{ENOSPC}, + \errval{EROFS}, nel loro significato generico.} \end{funcproto} La funzione apre il file indicato da \param{pathname} nella modalità indicata 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. La funzione restituisce il primo file descriptor libero. - -Quest'ultima caratteristica permette di prevedere sempre qual è il valore del -file descriptor che si otterrà al ritorno di \func{open}, e viene talvolta -usata da alcune applicazioni per sostituire i file corrispondenti ai file -standard visti in tab.~\ref{tab:file_std_files}. Se ad esempio si chiude lo -standard input e si apre subito dopo un nuovo file questo diventerà il nuovo -standard input (avrà cioè il file descriptor 0). +essergli assegnati. 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 \itindex{umask} \textit{umask} (vedi +sez.~\ref{sec:file_perm_management}) del processo. + +La funzione restituisce sempre il primo file descriptor libero, e questa +caratteristica permette di prevedere qual è il valore del file descriptor che +si otterrà al ritorno di \func{open}, e viene talvolta usata da alcune +applicazioni per sostituire i file corrispondenti ai file standard visti in +tab.~\ref{tab:file_std_files}. Se ad esempio si chiude lo +\itindex{standard~input} \textit{standard input} e si apre subito dopo un +nuovo file questo diventerà il nuovo \itindex{standard~input} \textit{standard + input} (avrà cioè il file descriptor 0). Al momento dell'apertura il nuovo file descriptor non è condiviso con nessun -altro processo (torneremo sulla condivisione dei file, in genere accessibile -dopo una \func{fork}, in sez.~\ref{sec:file_sharing}) ed è impostato per -restare aperto attraverso una \func{exec} (come accennato in -sez.~\ref{sec:proc_exec}). L'\textit{offset} è impostato all'inizio del file. +altro processo (torneremo sul significato della condivisione dei file +descriptor, che in genere si ottiene dopo una \func{fork}, in +sez.~\ref{sec:file_sharing}) ed è impostato, come accennato in +sez.~\ref{sec:proc_exec}, per restare aperto attraverso una +\func{exec}. Inoltre la posizione sul file, il cosiddetto \textit{offset}, è +impostata all'inizio del file. Una volta aperto un file si potrà operare su di +esso direttamente tramite il file descriptor, e quanto avviene al +\textit{pathname} con cui lo si è aperto sarà del tutto ininfluente. + +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 il +cosiddetto flag di stato del file (o \textit{file status flag}), che è il +valore mantenuto nel campo \var{f\_flags} della struttura \kstruct{file} che +abbiamo riportato anche in fig.~\ref{fig:file_proc_file}). + +Ciascun bit viene identificato da una apposita costante, ed il valore +di \param{flags} deve essere specificato come OR aritmetico di queste +costanti. I vari bit che si possono usare come componenti di \param{flags} +sono divisi in tre categorie principali. La prima categoria è quella dei +cosiddetti \textsl{i bit delle modalità di accesso}, che specificano con quale +modalità si accederà al file: i valori possibili sono lettura, scrittura o +lettura/scrittura. Uno di questi bit deve essere sempre specificato quando si +apre un file. Vengono impostati alla chiamata da \func{open}, e possono +essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}), +ma non possono essere modificati, le costanti che li identificano sono le +seguenti: -L'argomento opzionale \param{mode} indica i permessi con cui il file viene -creato ed 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 -filtrati dal valore di \itindex{umask} \textit{umask} (vedi -sez.~\ref{sec:file_perm_management}) per il processo. - -La funzione prevede diverse opzioni, che vengono specificate usando vari bit -dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire -il cosiddetto flag di stato del file (o \textit{file status flag}), che è -mantenuto nel campo \var{f\_flags} della struttura \kstruct{file} (al solito -si veda lo schema di fig.~\ref{fig:file_proc_file}). Essi sono divisi in tre -categorie principali: -\begin{itemize*} -\item \textsl{i bit delle modalità di accesso}: specificano con quale modalità - si accederà al file: i valori possibili sono lettura, scrittura o - lettura/scrittura. Uno di questi bit deve essere sempre specificato quando - si apre un file. Vengono impostati alla chiamata da \func{open}, e possono - essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}), - ma non possono essere modificati. \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}} -\item[\const{O\_RDONLY}] Apre il file in sola lettura, le \acr{glibc} - definiscono anche \const{O\_READ} come sinonimo. -\item[\const{O\_WRONLY}] Apre il file in sola scrittura, le \acr{glibc} - definiscono anche \const{O\_WRITE} come sinonimo. -\item[\const{O\_RDWR}] Apre il file sia in lettura che in scrittura. + \item[\const{O\_RDONLY}] Apre il file in sola lettura, le \acr{glibc} + definiscono anche \const{O\_READ} come sinonimo. + \item[\const{O\_WRONLY}] Apre il file in sola scrittura, le \acr{glibc} + definiscono anche \const{O\_WRITE} come sinonimo. + \item[\const{O\_RDWR}] Apre il file sia in lettura che in scrittura. \end{basedescript} -\item \textsl{i bit delle modalità di operazione}: permettono di specificare - alcune caratteristiche del comportamento delle future operazioni sul file - (come \func{read} o \func{write}). Anch'essi fan parte del \textit{file - status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma - possono essere riletti e modificati (insieme alle caratteristiche operative - che controllano) con una \func{fcntl}. + +La seconda categoria è quella dei \textsl{ bit delle modalità di operazione}, +che permettono di specificare alcune caratteristiche del comportamento delle +future operazioni sul file (come \func{read} o \func{write}). Anch'essi fan +parte del \textit{file status flag}. Il loro valore è impostato alla chiamata +di \func{open}, ma possono essere riletti e modificati (insieme alle +caratteristiche operative che controllano) con una \func{fcntl}. + \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}} -\item[\const{O\_CREAT}] Se il file non esiste verrà creato, con le regole di - titolarità del file viste in sez.~\ref{sec:file_ownership_management}. Con - questa opzione l'argomento \param{mode} deve essere specificato. - -\item[\const{O\_EXCL}] Usato in congiunzione con \const{O\_CREAT} fa sì che la - precedente esistenza del file diventi un errore\footnote{la pagina di - manuale di \func{open} segnala che questa opzione è difettosa su NFS, e - che i programmi che la usano per stabilire un \index{file!di lock} - \textsl{file di lock} possono incorrere in una \itindex{race~condition} - \textit{race condition}. Si consiglia come alternativa di usare un file - con un nome univoco e la funzione \func{link} per verificarne l'esistenza - (vedi sez.~\ref{sec:ipc_file_lock}).} che fa fallire \func{open} con - \errcode{EEXIST}. - -\item[\const{O\_NONBLOCK}] Apre il file in modalità non bloccante, e comporta - che \func{open} ritorni immediatamente anche quando dovrebbe bloccarsi - (l'opzione ha senso solo per le fifo, vedi sez.~\ref{sec:ipc_named_pipe}). - -\item[\const{O\_NOCTTY}] Se \param{pathname} si riferisce ad un dispositivo di - terminale, questo non diventerà il terminale di controllo, anche se il - processo non ne ha ancora uno (si veda sez.~\ref{sec:sess_ctrl_term}). - -\item[\const{O\_SHLOCK}] Apre il file con uno shared lock (vedi - sez.~\ref{sec:file_locking}). Specifica di BSD, assente in Linux. - -\item[\const{O\_EXLOCK}] Apre il file con un lock esclusivo (vedi - sez.~\ref{sec:file_locking}). Specifica di BSD, assente in Linux. - -\item[\const{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. - -\item[\const{O\_NOFOLLOW}] Se \param{pathname} è un link simbolico la chiamata - fallisce. Questa è un'estensione BSD aggiunta in Linux dal kernel - 2.1.126. Nelle versioni precedenti i link simbolici sono sempre seguiti, e - questa opzione è ignorata. - -\item[\const{O\_DIRECTORY}] Se \param{pathname} non è una directory la - chiamata fallisce. Questo flag è specifico di Linux ed è stato introdotto - con il kernel 2.1.126 per evitare dei \itindex{Denial~of~Service~(DoS)} - \textit{DoS}\footnote{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 bloccato nelle risposte all'attacco.} quando \func{opendir} - viene chiamata su una fifo o su un dispositivo associato ad una unità a - nastri, non deve dispositivo a nastri; non deve essere utilizzato - al di fuori dell'implementazione di \func{opendir}. - -\item[\const{O\_LARGEFILE}] Nel caso di sistemi a 32 bit che supportano file - di grandi dimensioni consente di aprire file le cui dimensioni non possono - essere rappresentate da numeri a 31 bit. + \item[\const{O\_CREAT}] Se il file non esiste verrà creato, con le regole di + titolarità del file viste in sez.~\ref{sec:file_ownership_management}. Con + questa opzione l'argomento \param{mode} deve essere specificato. + + \item[\const{O\_EXCL}] Usato in congiunzione con \const{O\_CREAT} fa sì che + la precedente esistenza del file diventi un errore\footnote{la pagina di + manuale di \func{open} segnala che questa opzione è difettosa su NFS, e + che i programmi che la usano per stabilire un \index{file!di lock} + \textsl{file di lock} possono incorrere in una \itindex{race~condition} + \textit{race condition}. Si consiglia come alternativa di usare un file + con un nome univoco e la funzione \func{link} per verificarne + l'esistenza (vedi sez.~\ref{sec:ipc_file_lock}).} che fa fallire + \func{open} con \errcode{EEXIST}. + + \item[\const{O\_NOCTTY}] Se \param{pathname} si riferisce ad un dispositivo + di terminale, questo non diventerà il terminale di controllo, anche se il + processo non ne ha ancora uno (si veda sez.~\ref{sec:sess_ctrl_term}). + + \item[\const{O\_SHLOCK}] Apre il file con uno shared lock (vedi + sez.~\ref{sec:file_locking}). Specifica di BSD, assente in Linux. + + \item[\const{O\_EXLOCK}] Apre il file con un lock esclusivo (vedi + sez.~\ref{sec:file_locking}). Specifica di BSD, assente in Linux. + + \item[\const{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. + + \item[\const{O\_NOFOLLOW}] Se \param{pathname} è un collegamento simbolico + la chiamata fallisce. Questa è un'estensione BSD aggiunta in Linux dal + kernel 2.1.126. Nelle versioni precedenti i collegamenti simbolici sono + sempre seguiti, e questa opzione è ignorata. + + \item[\const{O\_DIRECTORY}] Se \param{pathname} non è una directory la + chiamata fallisce. Questo flag è specifico di Linux ed è stato introdotto + con il kernel 2.1.126 per evitare dei \itindex{Denial~of~Service~(DoS)} + \textit{DoS}\footnote{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 bloccato nelle risposte all'attacco.} quando + \func{opendir} viene chiamata su una fifo o su un dispositivo associato ad + una unità a nastri, non deve dispositivo a nastri; non deve essere + utilizzato al di fuori dell'implementazione di \func{opendir}. + + \item[\const{O\_LARGEFILE}] Nel caso di sistemi a 32 bit che supportano file + di grandi dimensioni consente di aprire file le cui dimensioni non possono + essere rappresentate da numeri a 31 bit. \end{basedescript} -\item \textsl{i bit delle modalità di apertura}: permettono di specificare - alcune delle caratteristiche del comportamento di \func{open} quando viene - eseguita. Hanno effetto solo al momento della chiamata della funzione e non - sono memorizzati né possono essere riletti. + +La terza categoria è quella dei \textsl{i bit delle modalità di apertura} +che permettono di specificare alcune delle caratteristiche del comportamento +di \func{open} quando viene eseguita. Hanno effetto solo al momento della +chiamata della funzione e non sono memorizzati né possono essere riletti. + \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}} -\item[\const{O\_APPEND}] Il file viene aperto in \itindex{append~mode} - \textit{append mode}. Prima di ciascuna scrittura la posizione corrente - viene sempre impostata alla fine del file. Con NFS si può avere una - corruzione del file se più di un processo scrive allo stesso - tempo.\footnote{il problema è che NFS non supporta la scrittura in - \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma - questo comporta la possibilità di una \itindex{race~condition} - \textit{race condition}, vedi sez.~\ref{sec:file_atomic}.} - -\item[\const{O\_NONBLOCK}] Il file viene aperto in modalità non bloccante per - le operazioni di I/O (che tratteremo in sez.~\ref{sec:file_noblocking}): - questo significa il fallimento di \func{read} in assenza di dati da leggere - e quello di \func{write} in caso di impossibilità di scrivere - immediatamente. Questa modalità ha senso solo per le fifo e per alcuni file - di dispositivo. - -\item[\const{O\_NDELAY}] In Linux è sinonimo di - \const{O\_NONBLOCK}.\footnote{l'opzione origina da SVr4, dove però causava - il ritorno da una \func{read} con un valore nullo e non con un errore, - questo introduce un'ambiguità, dato che come vedremo in - sez.~\ref{sec:file_read} il ritorno di zero da parte di \func{read} ha il - significato di una \textit{end-of-file}.} - -\item[\const{O\_ASYNC}] Apre il file per l'I/O in modalità asincrona (vedi - sez.~\ref{sec:file_asyncronous_io}). Quando è impostato viene generato il - segnale \signal{SIGIO} tutte le volte che sono disponibili dati in input sul - file. - -\item[\const{O\_SYNC}] Apre il file per l'input/output sincrono: ogni - \func{write} bloccherà fino al completamento della scrittura di tutti i dati - sull'hardware sottostante. - -\item[\const{O\_FSYNC}] Sinonimo di \const{O\_SYNC}, usato da BSD. - -\item[\const{O\_DSYNC}] Variante di I/O sincrono definita da POSIX; presente - dal kernel 2.1.130 come sinonimo di \const{O\_SYNC}. - -\item[\const{O\_RSYNC}] Variante analoga alla precedente, trattata allo stesso - modo. - -\item[\const{O\_NOATIME}] Blocca l'aggiornamento dei tempi di accesso dei file - (vedi sez.~\ref{sec:file_file_times}). Per molti filesystem questa - funzionalità non è disponibile per il singolo file ma come opzione generale - da specificare in fase di montaggio. - -\item[\const{O\_DIRECT}] Esegue l'I/O direttamente dai buffer in user space in - maniera sincrona, in modo da scavalcare i meccanismi di caching del - kernel. In genere questo peggiora le prestazioni tranne quando le - applicazioni ottimizzano il proprio caching.\footnote{l'opzione è stata - introdotta dalla SGI in IRIX, e serve sostanzialmente a permettere ad - alcuni programmi (in genere database) la gestione diretta della - bufferizzazione dell'I/O in quanto essi sono in grado di ottimizzarla al - meglio per le loro prestazioni; l'opzione è presente anche in FreeBSD, - senza limiti di allineamento dei buffer. In Linux è stata introdotta con - il kernel 2.4.10, le versioni precedenti la ignorano.} Per i kernel della - serie 2.4 si deve garantire che i buffer in user space siano allineati alle - dimensioni dei blocchi del filesystem; per il kernel 2.6 basta che siano - allineati a multipli di 512 byte. - -\item[\const{O\_CLOEXEC}] Attiva la modalità di \itindex{close-on-exec} - \textit{close-on-exec} (vedi sez.~\ref{sec:file_sharing} e - \ref{sec:file_fcntl}).\footnote{introdotto con il kernel 2.6.23, per evitare - una \itindex{race~condition} \textit{race condition} che si può verificare - con i \itindex{thread} \textit{thread}, fra l'apertura del file e - l'impostazione della suddetta modalità con \func{fcntl}.} -\end{basedescript} -\end{itemize*} + \item[\const{O\_APPEND}] Il file viene aperto in \itindex{append~mode} + \textit{append mode}. Prima di ciascuna scrittura la posizione corrente + viene sempre impostata alla fine del file. Con NFS si può avere una + corruzione del file se più di un processo scrive allo stesso + tempo.\footnote{il problema è che NFS non supporta la scrittura in + \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma + questo comporta la possibilità di una \itindex{race~condition} + \textit{race condition}, vedi sez.~\ref{sec:file_atomic}.} + + \item[\const{O\_NONBLOCK}] Il file viene aperto in modalità non bloccante + per le operazioni di I/O (che tratteremo in + sez.~\ref{sec:file_noblocking}): questo significa il fallimento di + \func{read} in assenza di dati da leggere e quello di \func{write} in caso + di impossibilità di scrivere immediatamente. Questa modalità ha senso solo + per le fifo e per alcuni file di dispositivo. + + \item[\const{O\_NONBLOCK}] Apre il file in modalità non bloccante, e + comporta che \func{open} ritorni immediatamente anche quando dovrebbe + bloccarsi (l'opzione ha senso solo per le fifo, vedi + sez.~\ref{sec:ipc_named_pipe}). + + \item[\const{O\_NDELAY}] In Linux è sinonimo di + \const{O\_NONBLOCK}.\footnote{l'opzione origina da SVr4, dove però causava + il ritorno da una \func{read} con un valore nullo e non con un errore, + questo introduce un'ambiguità, dato che come vedremo in + sez.~\ref{sec:file_read} il ritorno di zero da parte di \func{read} ha + il significato di una \textit{end-of-file}.} + + \item[\const{O\_ASYNC}] Apre il file per l'I/O in modalità asincrona (vedi + sez.~\ref{sec:file_asyncronous_io}). Quando è impostato viene generato il + segnale \signal{SIGIO} tutte le volte che sono disponibili dati in input + sul file. + + \item[\const{O\_SYNC}] Apre il file per l'input/output sincrono: ogni + \func{write} bloccherà fino al completamento della scrittura di tutti i + dati sull'hardware sottostante. + + \item[\const{O\_FSYNC}] Sinonimo di \const{O\_SYNC}, usato da BSD. + + \item[\const{O\_DSYNC}] Variante di I/O sincrono definita da POSIX; presente + dal kernel 2.1.130 come sinonimo di \const{O\_SYNC}. + + \item[\const{O\_RSYNC}] Variante analoga alla precedente, trattata allo + stesso modo. + + \item[\const{O\_NOATIME}] Blocca l'aggiornamento dei tempi di accesso dei + file (vedi sez.~\ref{sec:file_file_times}). Per molti filesystem questa + funzionalità non è disponibile per il singolo file ma come opzione + generale da specificare in fase di montaggio. + + \item[\const{O\_DIRECT}] Esegue l'I/O direttamente dai buffer in user space + in maniera sincrona, in modo da scavalcare i meccanismi di caching del + kernel. In genere questo peggiora le prestazioni tranne quando le + applicazioni ottimizzano il proprio caching.\footnote{l'opzione è stata + introdotta dalla SGI in IRIX, e serve sostanzialmente a permettere ad + alcuni programmi (in genere database) la gestione diretta della + bufferizzazione dell'I/O in quanto essi sono in grado di ottimizzarla al + meglio per le loro prestazioni; l'opzione è presente anche in FreeBSD, + senza limiti di allineamento dei buffer. In Linux è stata introdotta con + il kernel 2.4.10, le versioni precedenti la ignorano.} Per i kernel + della serie 2.4 si deve garantire che i buffer in user space siano + allineati alle dimensioni dei blocchi del filesystem; per il kernel 2.6 + basta che siano allineati a multipli di 512 byte. + + \item[\const{O\_CLOEXEC}] Attiva la modalità di \itindex{close-on-exec} + \textit{close-on-exec} (vedi sez.~\ref{sec:file_sharing} e + \ref{sec:file_fcntl}).\footnote{introdotto con il kernel 2.6.23, per + evitare una \itindex{race~condition} \textit{race condition} che si può + verificare con i \itindex{thread} \textit{thread}, fra l'apertura del + file e l'impostazione della suddetta modalità con \func{fcntl}.} + \end{basedescript} %TODO trattare le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella @@ -1304,7 +1329,7 @@ prevista anche l'aggiunta di un ulteriore argomento finale, \param{flags}. 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 link simbolico, così da poter scegliere se far agire la funzione +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 @@ -1333,14 +1358,14 @@ che \func{lchown}; il suo prototipo è: \end{functions} In questo caso il valore di \param{flags} stabilisce il comportamento della -funzione quando la si applica ad un link simbolico, e l'unico valore +funzione quando la si applica ad un collegamento simbolico, e l'unico valore utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \headfile{fcntl.h} è definito anche \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i - link simbolici, essendo questo però il comportamento adottato per un valore - nullo di \param{flags} questo valore non viene mai usato.} che se impostato -indica alla funzione di non eseguire la dereferenziazione di un eventuale link -simbolico, facendo comportare \func{fchownat} come \func{lchown} invece che -come \func{chown}. + collegamenti simbolici, essendo questo però il comportamento adottato per un + valore nullo di \param{flags} questo valore non viene mai usato.} 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}. Come accennato fra tutte quelle marcate in tab.~\ref{tab:file_atfunc_corr} solo due funzioni possono usare l'argomento \param{flags} con valori diversi @@ -1371,8 +1396,8 @@ esso può essere specificato come maschera binaria di due valori: dei permessi usando l'\ids{UID} effettivo invece di quello reale (il comportamento di default, che riprende quello di \func{access}). \item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato \funcd{faccessat} non esegue - la dereferenziazione dei link simbolici, effettuando il controllo dei - permessi direttamente sugli stessi. + la dereferenziazione dei collegamenti simbolici, effettuando il controllo + dei permessi direttamente sugli stessi. \end{basedescript} La seconda eccezione è \func{unlinkat}, in questo caso l'ulteriore -- 2.30.2