\texttt{(unreachable)} se la directory di lavoro resta fuori dalla directory
radice del processo dopo un \func{chroot} (torneremo su questi argomenti in
sez.~\ref{sec:file_chroot}); pertanto è sempre opportuno controllare il primo
-carattere della stringa restituita dalla funzione per evitare di interpreare
+carattere della stringa restituita dalla funzione per evitare di interpretare
mare un \textit{pathname} irraggiungibile.
Come estensione allo standard POSIX.1, supportata da Linux e dalla
\func{mkstemp}.}
\end{funcproto}
\noindent la cui sola differenza è la presenza dell'ulteriore argomento
-\var{flags} che consente di specificare alcuni ulteriori flag
-(\const{O\_APPEND}, \const{O\_CLOEXEC}, \const{O\_SYNC}, il cui significato
+\var{flags} che consente di specificare alcuni ulteriori flag (come
+\const{O\_APPEND}, \const{O\_CLOEXEC}, \const{O\_SYNC}, il cui significato
vedremo in sez.~\ref{sec:file_open_close}) da passare ad \func{open}
-nell'apertura del file.
+nell'apertura del file.\footnote{si tenga presente che \func{mkostemp}
+ utilizza già \const{O\_CREAT}, \const{O\_EXCL} e \const{O\_RDWR}, che non è
+ il caso di riindicare, dato che ciò potrebbe portare ad errori in altri
+ sistemi operativi.}
-Di queste due funzioni sono state poi introdotte a partire dalla \acr{glibc}
-2.11 due varianti, \funcd{mkstemps} e \funcd{mkostemps} che consentono di
-indicare anche un suffisso, i loro prototipo sono:
+Di queste due funzioni sono state poi introdotte, a partire dalla \acr{glibc}
+2.11 due varianti, \funcd{mkstemps} e \funcd{mkostemps}, che consentono di
+indicare anche un suffisso, i loro prototipi sono:
\begin{funcproto}{
\fhead{stlib.h}
}
{Le funzioni hanno gli stessi valori di ritorno e gli stessi errori di
- \func{mkstemp} con lo stesso significato tranne \errval{EINVAL} che viene
+ \func{mkstemp} con lo stesso significato, tranne \errval{EINVAL} che viene
restituito se \param{template} non è di lunghezza pari ad almeno
$6+$\param{suffixlen} ed i 6 caratteri prima del suffisso non sono
\code{XXXXXX}.}
\end{funcproto}
-Le due funzioni, estensione non standard delle \acr{glibc}, sono identiche a
-\funcd{mkstemp} e \funcd{mkostemp}, ma consentono di avere un nome del file
-nella forma \texttt{prefissoXXXXXXsuffisso} dove la lunghezza del suffisso
-deve essere indicata con \param{suffixlen}.
+Le due funzioni, un'estensione non standard fornita dalla \acr{glibc}, sono
+identiche a \funcd{mkstemp} e \funcd{mkostemp}, ma consentono di avere un nome
+del file nella forma \texttt{prefissoXXXXXXsuffisso} dove la lunghezza del
+suffisso deve essere indicata con \param{suffixlen}.
Infine con OpenBSD è stata introdotta un'altra funzione simile alle
precedenti, \funcd{mkdtemp}, che crea invece una directory
non si pongono.
-
\section{La manipolazione delle caratteristiche dei file}
\label{sec:file_infos}
campi di \struct{stat} su cui non torneremo in maggior dettaglio nel resto di
questa sezione:
\begin{itemize*}
-
\item Il campo \var{st\_nlink} contiene il numero di \textit{hard link} che
fanno riferimento al file (il cosiddetto \textit{link count}) di cui abbiamo
già parlato in numerose occasioni.
-
\item Il campo \var{st\_ino} contiene il numero di \textit{inode} del file,
quello viene usato all'interno del filesystem per identificarlo e che può
essere usato da un programma per determinare se due \textit{pathname} fanno
riferimento allo stesso file.
-
\item Il campo \var{st\_dev} contiene il numero del dispositivo su cui risiede
il file (o meglio il suo filesystem). Si tratta dello stesso numero che si
usa con \func{mknod} e che può essere decomposto in \textit{major number} e
\textit{minor number} con le macro \macro{major} e \macro{minor} viste in
sez.~\ref{sec:file_mknod}.
-
\item Il campo \var{st\_rdev} contiene il numero di dispositivo associato al
file stesso ed ovviamente ha un valore significativo soltanto quando il file
è un dispositivo a caratteri o a blocchi.
-
\item Il campo \var{st\_blksize} contiene la dimensione dei blocchi di dati
usati nell'I/O su disco, che è anche la dimensione usata per la
bufferizzazione dei dati dalle librerie del C per l'interfaccia degli
\textit{stream}. Leggere o scrivere blocchi di dati in dimensioni inferiori
a questo valore è inefficiente in quanto le operazioni su disco usano
comunque trasferimenti di questa dimensione.
-
\end{itemize*}
-% TODO trattare anche statx, aggiunta con il kernel 4.11 (vedi
-% https://lwn.net/Articles/707602/ e
-% https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f)
+Nell'evoluzione del kernel la \textit{system call} che fornisce \func{stat} è
+stata modificata più volte per tener conto dei cambiamenti fatti alla
+struttura \struct{stat},\footnote{questo ha significato l'utilizzo a basso
+ livello di diverse \textit{system call} e diverse versioni della struttura.}
+in particolare a riguardo ai tempi dei file, di cui è stata aumentata la
+precisione (torneremo su questo in sez.~\ref{sec:file_file_times}) ma anche
+per gli aggiornamenti fatti ai campi \var{st\_ino}, \var{st\_uid} e
+\var{st\_gid}.
+
+Sulle piattaforme a 32 bit questi cambiamenti, che han visto un aumento delle
+dimensioni dei campi della struttura per adattarli alle nuove esigenze, sono
+mascherati dalla \acr{glibc} che attraverso \func{stat} invoca la versione più
+recente della \textit{system call} e rimpacchetta i dati se questo è
+necessario per eseguire dei vecchi programmi. Nelle piattaforme a 64 bit
+invece è presente un'unica versione della \textit{system call} e la struttura
+\struct{stat} ha campi di dimensione sufficiente.
+
+Infine a partire dal kernel 2.6.16 è stata introdotta una ulteriore funzione
+della famiglia, \func{fstatat} che consente di trattare con sicurezza i
+\textit{pathname} relativi, la tratteremo in sez.~\ref{sec:file_openat},
+insieme alla nuova \textit{system call} \func{statx}, introdotta dal kernel
+4.11 per estendere l'interfaccia di \func{stat} e le informazioni che essa può
+restituire.
\subsection{I tipi di file}
funzioni della famiglia \func{stat} all'interno del campo \var{st\_mode} di
una struttura \struct{stat}.
-Il campo \var{st\_mode} è una maschera binaria in cui l'informazione viene
-suddivisa nei vari bit che compongono, ed oltre a quelle sul tipo di file,
-contiene anche le informazioni relative ai permessi su cui torneremo in
-sez.~\ref{sec:file_perm_overview}. Dato che i valori numerici usati per
-definire il tipo di file possono variare a seconda delle implementazioni, lo
-standard POSIX definisce un insieme di macro che consentono di verificare il
-tipo di file in maniera standardizzata.
-
\begin{table}[htb]
\centering
\footnotesize
\label{tab:file_type_macro}
\end{table}
+Il campo \var{st\_mode} è una maschera binaria in cui l'informazione viene
+suddivisa nei vari bit che compongono, ed oltre a quelle sul tipo di file,
+contiene anche le informazioni relative ai permessi su cui torneremo in
+sez.~\ref{sec:file_perm_overview}. Dato che i valori numerici usati per
+definire il tipo di file possono variare a seconda delle implementazioni, lo
+standard POSIX definisce un insieme di macro che consentono di verificare il
+tipo di file in maniera standardizzata.
+
Queste macro vengono usate anche da Linux che supporta pure le estensioni allo
standard per i collegamenti simbolici e i socket definite da BSD.\footnote{le
ultime due macro di tab.~\ref{tab:file_type_macro}, che non sono presenti
\label{sec:file_file_size}
Abbiamo visto in fig.~\ref{fig:file_stat_struct} che campo \var{st\_size} di
-una struttura \struct{stat} contiene la dimensione del file in byte. Questo
-però è vero solo se si tratta di un file regolare, mentre nel caso di un
-collegamento simbolico la dimensione è quella del \textit{pathname} che il
-collegamento stesso contiene, infine per le \textit{fifo} ed i file di dispositivo
-questo campo è sempre nullo.
-
-Il campo \var{st\_blocks} invece definisce la lunghezza del file in blocchi di
-512 byte. La differenza con \var{st\_size} è che in questo caso si fa
-riferimento alla quantità di spazio disco allocata per il file, e non alla
-dimensione dello stesso che si otterrebbe leggendolo sequenzialmente.
+una struttura \struct{stat} contiene la dimensione del file in byte. In realtà
+questo è vero solo se si tratta di un file regolare contenente dei dati; nel
+caso di un collegamento simbolico invece la dimensione è quella del
+\textit{pathname} che il collegamento stesso contiene, e per una directory
+quella dello spazio occupato per le voci della stessa (che dipende da come
+queste vengono mantenute dal filesystem), infine per le \textit{fifo}, i socket
+ed i file di dispositivo questo campo è sempre nullo.
+
+Il campo \var{st\_blocks} invece definisce la lunghezza del file espressa in
+numero di blocchi di 512 byte. La differenza con \var{st\_size} è che in
+questo caso si fa riferimento alla quantità di spazio disco allocata per il
+file, e non alla dimensione dello stesso che si otterrebbe leggendolo
+sequenzialmente.
Si deve tener presente infatti che la lunghezza del file riportata in
\var{st\_size} non è detto che corrisponda all'occupazione dello spazio su
In questo caso si avranno risultati differenti a seconda del modo in cui si
calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
-legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
-caso per i ``\textsl{buchi}'' vengono restituiti degli zeri, si avrà lo stesso
-risultato di \cmd{ls}.
+legge il contenuto del file (ad esempio usando il comando \cmd{wc -c}), dato
+che in tal caso per i ``\textsl{buchi}'' vengono restituiti degli zeri, si
+avrà lo stesso risultato di \cmd{ls}.
Se è sempre possibile allargare un file, scrivendoci sopra o usando la
funzione \func{lseek} (vedi sez.~\ref{sec:file_lseek}) per spostarsi oltre la
nuova fine del file.
Un file può sempre essere troncato a zero aprendolo con il flag
-\const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
-dimensione si possono usare le due funzioni di sistema \funcd{truncate} e
-\funcd{ftruncate}, i cui prototipi sono:
+\const{O\_TRUNC} (vedi sez.~\ref{sec:file_open_close}), ma questo è un caso
+particolare; per qualunque altra dimensione si possono usare le due funzioni
+di sistema \funcd{truncate} e \funcd{ftruncate}, i cui prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza
sui tre tempi. Il comando \cmd{ls} (quando usato con le opzioni \cmd{-l} o
\cmd{-t}) mostra i tempi dei file secondo lo schema riportato nell'ultima
-colonna di tab.~\ref{tab:file_file_times}. Si noti anche come non esista, a
-differenza di altri sistemi operativi, un \textsl{tempo di creazione} di un
-file.
+colonna di tab.~\ref{tab:file_file_times}. Si noti anche come in
+tab.~\ref{tab:file_file_times} non venga riportato il \textsl{tempo di
+ creazione} di un file. In un sistema unix-like infatti questo tempo
+tradizionalmente non esiste, e non è previsto dall'interfaccia classica, ma è
+usato da altri sistemi operativi (in particolare Windows) per cui in tutti i
+filesystem più recenti ne viene supportata la registrazione, ed a partire dal
+kernel 4.11 è divento possibile anche ottenerne la lettura con la nuova
+\textit{system call} \func{statx} (che tratteremo in
+sez.~\ref{sec:file_openat}).
L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
difetto progettuale di Unix, questo infatti comporta la necessità di
in termini di prestazioni, che di consumo di risorse come la batteria per i
portatili, o i cicli di riscrittura per i dischi su memorie riscrivibili.
-
-Per questo motivo abbiamo visto in sez.~\ref{sec:filesystem_mounting} come
-nello sviluppo del kernel siano stati introdotti degli opportuni \textit{mount
- flag} che consentissero di evitare di aggiornare continuamente una
-informazione che nella maggior parte dei casi non interessa. Per questo i
-valori che si possono trovare per l'\textit{access time} dipendono dalle
-opzioni di montaggio, ed anche, essendo stato cambiato il comportamento di
-default a partire dalla versione 2.6.30, dal kernel che si sta usando.
-
-In generale quello che si ha con i kernel più recenti è che il tempo di ultimo
-accesso viene aggiornato solo se è precedente al tempo di ultima modifica o
-cambiamento, o se è passato più di un giorno dall'ultimo accesso. Così si può
-rendere evidente che vi è stato un accesso dopo una modifica e che il file
-viene comunque osservato regolarmente, conservando tutte le informazioni
-veramente utili senza dover consumare risorse in scritture continue per
-mantenere costantemente aggiornata una informazione che a questo punto non ha
-più nessuna rilevanza pratica.\footnote{qualora ce ne fosse la necessità è
- comunque possibile, tramite l'opzione di montaggio \texttt{strictatime},
- richiedere in ogni caso il comportamento tradizionale.}
+Per questo motivo abbiamo visto in sez.~\ref{sec:filesystem_mounting} come nel
+corso dello sviluppo del kernel siano stati introdotti degli opportuni
+\textit{mount flag} che consentono di evitare di aggiornare continuamente una
+informazione che nella maggior parte dei casi non ha un interesse
+rilevante. Per questo motivo i valori dell'\textit{access time} possono
+dipendere dalle opzioni di montaggio, ed anche, essendo stato cambiato il
+comportamento di default a partire dalla versione 2.6.30, dal kernel che si
+sta usando.
+
+In generale quello che avviene con i kernel più recenti è che il tempo di
+ultimo accesso viene aggiornato solo se è precedente al tempo di ultima
+modifica o cambiamento, o se è cambiato ed passato più di un giorno
+dall'ultimo aggiornamento. Così si può rendere evidente che vi è stato un
+accesso dopo una modifica, e che il file viene comunque osservato a cadenza
+regolare, conservando le informazioni veramente utili senza consumare
+inutilmente risorse in continue scritture per mantenere costantemente
+aggiornata una informazione che a questo punto non ha più nessuna rilevanza
+pratica.\footnote{qualora ce ne fosse la necessità è comunque possibile,
+ tramite l'opzione di montaggio \texttt{strictatime}, richiedere in ogni caso
+ il comportamento tradizionale.}
\begin{table}[htb]
\centering
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
-nanosecondi per la gran parte dei filesystem. La ulteriore informazione può
-essere acceduta attraverso altri campi appositamente aggiunti alla struttura
+nanosecondi per la gran parte dei filesystem. L'ulteriore informazione può
+essere ottenuta attraverso altri campi appositamente aggiunti alla struttura
\struct{stat}. Se si sono definite le macro \macro{\_BSD\_SOURCE} o
\macro{\_SVID\_SOURCE} questi sono \var{st\_atim.tv\_nsec},
\var{st\_mtim.tv\_nsec} e \var{st\_ctim.tv\_nsec} se queste non sono definite,
\label{fig:sys_timeval_struct}
\end{figure}
-Oltre ad \func{utimes} su Linux sono presenti altre due funzioni,\footnote{le
- due funzioni non sono definite in nessuno standard, ma sono presenti, oltre
- che su Linux, anche su BSD.} \funcd{futimes} e \funcd{lutimes}, che
-consentono rispettivamente di effettuare la modifica utilizzando un file già
-aperto o di eseguirla direttamente su un collegamento simbolico. I relativi
-prototipi sono:
+
+
+
+Oltre ad \func{utimes} su Linux sono presenti altre due funzioni per la
+manipolazione dei tempi dei file,\footnote{le due funzioni non sono definite
+ in nessuno standard, ma sono presenti, oltre che su Linux, anche su BSD;
+ sono accessibili definendo \macro{\_DEFAULT\_SOURCE} dalla \acr{glibc} 2.19
+ o \macro{\_GNU\_SOURCE} prima.} la prima è \funcd{futimes} e consente di
+effettuare la modifica utilizzando un file già aperto, il suo prototipo è:
\begin{funcproto}{
\fhead{sys/time.h}
\fdecl{int futimes(int fd, const struct timeval tv[2])}
\fdesc{Cambia i tempi di un file già aperto.}
-\fdecl{int lutimes(const char *filename, const struct timeval tv[2])}
-\fdesc{Cambia i tempi di un collegamento simbolico.}
}
-{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà uno gli stessi valori di \func{utimes}, con in più
- per \func{futimes}:
+{La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno gli stessi valori di \func{utimes} ed inoltre:
\begin{errlist}
\item[\errcode{EBADF}] \param{fd} non è un file descriptor.
\item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
\end{errlist}}
\end{funcproto}
+La seconda funzione, introdotta a partire dal kernel 2.6.22, è
+\funcd{lutimes}, e consente rispettivamente di modificare i tempi di un
+collegamento simbolico; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fdecl{int lutimes(const char *filename, const struct timeval tv[2])}
+\fdesc{Cambia i tempi di un collegamento simbolico.}
+}
+
+{La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno gli stessi valori di \func{utimes}, con in più:
+ \begin{errlist}
+ \item[\errcode{ENOSYS}] la funzione non è supportata.
+ \end{errlist}}
+\end{funcproto}
+
Le due funzioni hanno lo stesso comportamento di \texttt{utimes} e richiedono
gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
si può indicare il file su cui operare se questo è già aperto facendo
% LocalWords: setmntent getmntent addmntent endmntent hasmntopt such offsetof
% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev FDCWD functions
% LocalWords: faccessat grpid lacl AppArmor capsetp mygetfacl table Tb MSK
-% LocalWords: LAZYTIME submount peer protected hardlink symlinks silly
+% LocalWords: LAZYTIME submount peer protected hardlink symlinks silly RDWR
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
-% LocalWords: renames
+% LocalWords: renames unreachable CLOEXEC mkstemps mkostemps suffixlen Aug
+% LocalWords: prefissoXXXXXXsuffisso nell'I fstatat statx sull' drwxrwxrwt
+% LocalWords: Disalloca
projects / gapil.git / blobdiff