%% fileunix.tex
%%
-%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2012 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",
error}\\
\hline
\end{tabular}
- \caption{Costanti definite in \file{unistd.h} per i file standard aperti
+ \caption{Costanti definite in \headfile{unistd.h} per i file standard aperti
alla creazione di ogni processo.}
\label{tab:file_std_files}
\end{table}
\label{sec:file_open}
La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è
-quella che crea l'associazione fra un \itindex{pathname} \textit{pathname} ed
-un \itindex{file~descriptor} file descriptor, il suo prototipo è:
+quella che crea l'associazione fra un \textit{pathname} ed un
+\itindex{file~descriptor} file descriptor, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
#define _XOPEN_SOURCE 500
\end{verbatim}
e si ricordi di definire questa macro prima dell'inclusione del file di
-dichiarazioni \file{unistd.h}.
+dichiarazioni \headfile{unistd.h}.
\label{sec:file_openat}
Un problema che si pone con l'uso della funzione \func{open}, così come per
-molte altre funzioni che accettano come argomenti dei pathname relativi, è
-che, quando un pathname relativo non fa riferimento alla directory di lavoro
-corrente, è possibile che alcuni dei suoi componenti vengano modificati in
-parallelo alla chiamata a \func{open}, e questo lascia aperta la possibilità
-di una \itindex{race~condition} \textit{race condition}.
-
-Inoltre come già accennato, la directory di lavoro corrente è una proprietà
-del singolo processo; questo significa che quando si lavora con i
-\itindex{thread} \textit{thread} essa sarà la stessa per tutti, ma esistono
-molti casi in cui sarebbe invece utile che ogni singolo \itindex{thread}
-\textit{thread} avesse la sua directory di lavoro.
+molte altre funzioni che accettano come argomenti dei
+\itindsub{pathname}{relativo} \textit{pathname} relativi, è che, quando un
+\textit{pathname} relativo non fa riferimento alla \index{directory~di~lavoro}
+directory di lavoro corrente, è possibile che alcuni dei suoi componenti
+vengano modificati in parallelo alla chiamata a \func{open}, e questo lascia
+aperta la possibilità di una \itindex{race~condition} \textit{race condition}.
+
+Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
+corrente è una proprietà del singolo processo; questo significa che quando si
+lavora con i \itindex{thread} \textit{thread} essa sarà la stessa per tutti,
+ma esistono molti casi in cui sarebbe invece utile che ogni singolo
+\itindex{thread} \textit{thread} avesse la sua \index{directory~di~lavoro}
+directory di lavoro.
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 funzioni ``\textit{at}'' in quanto contraddistinte dal
suffisso \texttt{at}, che permettono l'apertura di un file (o le rispettive
-altre operazioni) usando un pathname relativo ad una directory
-specificata.\footnote{l'introduzione è avvenuta su proposta dello sviluppatore
- principale delle \acr{glibc} Urlich Drepper; le corrispondenti system call
- sono state inserite nel kernel ufficiale a partire dalla versione 2.6.16, in
- precedenza era disponibile una emulazione che, sia pure con prestazioni
- inferiori, funzionava facendo ricorso all'uso del filesystem \textit{proc}
- con l'apertura del file attraverso il riferimento a pathname del tipo di
+altre operazioni) usando un \itindsub{pathname}{relativo} \textit{pathname}
+relativo ad una directory specificata.\footnote{l'introduzione è avvenuta su
+ proposta dello sviluppatore principale delle \acr{glibc} Urlich Drepper; le
+ corrispondenti system call sono state inserite nel kernel ufficiale a
+ partire dalla versione 2.6.16, in precedenza era disponibile una emulazione
+ che, sia pure con prestazioni inferiori, funzionava facendo ricorso all'uso
+ del filesystem \textit{proc} con l'apertura del file attraverso il
+ riferimento a \textit{pathname} del tipo di
\texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste funzioni non
siano presenti negli standard tradizionali esse sono state adottate da vari
Unix\footnote{oltre a Linux e Solaris sono presenti in vari BSD.} fino ad
definire la macro \macro{\_ATFILE\_SOURCE}.
L'uso di queste funzioni prevede una apertura iniziale della directory che
-sarà la base della risoluzione dei 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.\footnote{in questo modo, anche quando si lavora con i
- \itindex{thread} \textit{thread}, si può mantenere una directory di lavoro
- diversa per ciascuno di essi.}
+sarà la base della risoluzione dei \itindsub{pathname}{relativo}
+\textit{pathname} relativi che verranno usati in seguito, dopo di che si dovrà
+passare il relativo file descriptor alle varie funzioni che useranno quella
+directory come punto di partenza per la risoluzione.\footnote{in questo modo,
+ anche quando si lavora con i \itindex{thread} \textit{thread}, si può
+ mantenere una \index{directory~di~lavoro} directory di lavoro diversa per
+ ciascuno di essi.}
Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
\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 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.
+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, mentre gli
\funcdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t
mode))}
- Apre un file usando come directory di lavoro corrente \param{dirfd}.
+ Apre un file usando come directory di \index{directory~di~lavoro} lavoro
+ corrente \param{dirfd}.
\bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
errore di \func{open}, ed in più:
\begin{errlist}
\item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
- \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
+ \textit{pathname} relativo, ma
\param{dirfd} fa riferimento ad un file.
\end{errlist}}
\end{functions}
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 pathname relativo questo sarà risolto rispetto alla
-directory indicata da \param{dirfd}; qualora invece si usi un pathname
-assoluto \param{dirfd} verrà semplicemente ignorato. Infine se per
+argomenti si utilizza un \itindsub{pathname}{relativo} \textit{pathname}
+relativo questo sarà risolto rispetto alla directory indicata
+da \param{dirfd}; qualora invece si usi un \itindsub{pathname}{assoluto}
+\textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
+se per
\param{dirfd} si usa il valore speciale \const{AT\_FDCWD},\footnote{questa,
- come le altre costanti \texttt{AT\_*}, è definita in \texttt{fcntl.h},
+ 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.} la risoluzione sarà
-effettuata rispetto alla directory di lavoro corrente del processo.
+effettuata rispetto alla directory di \index{directory~di~lavoro} lavoro
+corrente del processo.
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
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.\footnote{tranne il caso in cui si sia specificato un
- pathname assoluto, nel qual caso, come detto, il valore di \param{dirfd}
- sarà completamente ignorato.}
+descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa
+riferimento ad una directory.\footnote{tranne il caso in cui si sia
+ specificato un \itindsub{pathname}{assoluto} \textit{pathname} assoluto, nel
+ qual caso, come detto, il valore di \param{dirfd} sarà completamente
+ ignorato.}
In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte
con questa nuova interfaccia, con a fianco la corrispondente funzione
\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
utilizzabile solo a partire dal kernel 2.6.18.}
+% TODO manca prototipo di fchmodat
+
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
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 \texttt{fcntl.h}.
+\texttt{AT\_*}, definite in \headfile{fcntl.h}.
Come esempio di questo secondo tipo di funzioni possiamo considerare
\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
\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 pathname relativo, ma
- \param{dirfd} fa riferimento ad un file.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
+ \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
\end{errlist}}
\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
-utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \texttt{fcntl.h} è
+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
\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 pathname relativo, ma
- \param{dirfd} fa riferimento ad un file.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
+ \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
\end{errlist}}
\end{functions}
il comportamento rispetto a quello ordinario di \func{access}. In questo caso
esso può essere specificato come maschera binaria di due valori:
\begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\const{AT\_EACCESS}] se impostato \funcd{faccessat} esegue il controllo
- dei permessi usando l'\acr{uid} effettivo invece di quello reale (il
+\item[\const{AT\_EACCES}] se impostato \funcd{faccessat} esegue il controllo
+ 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
\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 pathname relativo, ma
- \param{dirfd} fa riferimento ad un file.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
+ \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
\end{errlist}}
\end{functions}
imposta \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore
nullo. Questa funzionalità è trattata in dettaglio in
sez.~\ref{sec:file_posix_lock}.
-\item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o
+\item[\const{F\_GETOWN}] restituisce il \ids{PID} del processo o
l'identificatore del \itindex{process~group} \textit{process
group}\footnote{i \itindex{process~group} \textit{process group} sono
(vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel
controllo di sessione; a ciascuno di essi è associato un identificatore
- (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione
+ (un numero positivo analogo al \ids{PID}).} che è preposto alla ricezione
dei segnali \signal{SIGIO}\footnote{o qualunque altro segnale alternativo
impostato con \const{F\_FSETSIG}.} per gli eventi associati al file
descriptor \param{fd}\footnote{il segnale viene usato sia per il
queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
motivo il valore della modalità di accesso corrente si ottiene eseguendo un
AND binario del valore di ritorno di \func{fcntl} con la maschera
-\const{O\_ACCMODE} (anch'essa definita in \file{fcntl.h}), che estrae i bit di
-accesso dal \textit{file status flag}.
+\const{O\_ACCMODE} (anch'essa definita in \headfile{fcntl.h}), che estrae i
+bit di accesso dal \textit{file status flag}.
In generale ogni dispositivo ha un suo insieme di operazioni specifiche
effettuabili attraverso \func{ioctl}, tutte queste sono definite nell'header
-file \file{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui fanno
-riferimento. Infatti anche se in genere i valori di \param{request} sono
+file \headfile{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui
+fanno riferimento. Infatti anche se in genere i valori di \param{request} sono
opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
un apposito \textit{magic number} per distinguere ciascun dispositivo nella
definizione delle macro da usare per \param{request}, in modo da essere
% LocalWords: Drepper path dirfd faccessat unlinkat access fchmodat chmod Di
% LocalWords: fchownat chown fstatat futimesat utimes linkat mknodat mknod uid
% LocalWords: readlinkat readlink renameat rename symlinkat symlink unlink gid
-% LocalWords: mkfifoat mkfifo FDCWD EACCESS dereferenziazione rmdir REMOVEDIR
+% LocalWords: mkfifoat mkfifo FDCWD dereferenziazione rmdir REMOVEDIR
% LocalWords: epoll lsattr chattr FIOQSIZE ATFILE lutimes utimensat lchown
% LocalWords: lstat owner FOLLOW