\section{La gestione di file e directory}
\label{sec:file_dir}
-Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like la
-gestione dei file ha delle caratteristiche specifiche che derivano
-direttamente dall'architettura del sistema.
-
-In questa sezione esamineremo le funzioni usate per la manipolazione di file e
-directory, per la creazione di link simbolici e diretti, per la gestione e la
-lettura delle directory.
+Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like
+la gestione dei file ha delle caratteristiche specifiche che derivano
+direttamente dall'architettura del sistema. In questa sezione esamineremo le
+funzioni usate per la manipolazione di file e directory, per la creazione di
+link simbolici e diretti, per la gestione e la lettura delle directory.
In particolare ci soffermeremo sulle conseguenze che derivano
dall'architettura dei filesystem illustrata nel capitolo precedente per quanto
-riguarda il comportamento delle varie funzioni.
+riguarda il comportamento e gli effetti delle varie funzioni.
\subsection{Le funzioni \func{link} e \func{unlink}}
fare questa operazione.
Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un
-file su disco avviene passando attraverso il suo \index{inode} inode, che è la
-struttura usata dal kernel che lo identifica univocamente all'interno di un
-singolo filesystem. Il nome del file che si trova nella voce di una directory
-è solo un'etichetta, mantenuta all'interno della directory, che viene
-associata ad un puntatore che fa riferimento al suddetto inode.
+file su disco avviene passando attraverso il suo \itindex{inode}
+\textit{inode}, che è la struttura usata dal kernel che lo identifica
+univocamente all'interno di un singolo filesystem. Il nome del file che si
+trova nella voce di una directory è solo un'etichetta, mantenuta all'interno
+della directory, che viene associata ad un puntatore che fa riferimento al
+suddetto \textit{inode}.
Questo significa che, fintanto che si resta sullo stesso filesystem, la
realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi
-diversi, dati da altrettante diverse associazioni allo stesso \index{inode}
-inode di etichette diverse in directory diverse. Si noti anche che nessuno di
-questi nomi viene ad assumere una particolare preferenza o originalità
-rispetto agli altri, in quanto tutti fanno comunque riferimento allo stesso
-\index{inode} inode.
+diversi, dati da altrettante associazioni diverse allo stesso \itindex{inode}
+\textit{inode} effettuate tramite ``etichette'' diverse in directory
+diverse. Si noti anche che nessuno di questi nomi viene ad assumere una
+particolare preferenza o originalità rispetto agli altri, in quanto tutti
+fanno comunque riferimento allo stesso \itindex{inode} \textit{inode}.
Per aggiungere ad una directory una voce che faccia riferimento ad un
-\index{inode} inode già esistente si utilizza la funzione \func{link}; si
-suole chiamare questo tipo di associazione un collegamento diretto (o
-\textit{hard link}). Il prototipo della funzione è:
+\itindex{inode} \textit{inode} già esistente si utilizza la funzione
+\func{link}; si suole chiamare questo tipo di associazione un collegamento
+diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:
\begin{prototype}{unistd.h}
{int link(const char *oldpath, const char *newpath)}
Crea un nuovo collegamento diretto.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore nel qual caso \var{errno} viene impostata ai valori:
\begin{errlist}
- \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non sono
- sullo stesso filesystem.
+ \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
+ riferimento ad un filesystem montato sullo stesso \textit{mount point}.
\item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
\param{newpath} non supporta i link diretti o è una directory.
- \item[\errcode{EEXIST}] un file (o una directory) con quel nome esiste di
- già.
+ \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
+ esiste già.
\item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il
numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
sez.~\ref{sec:sys_limits}).
\var{st\_nlink} della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat})
aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
essere così chiamato con vari nomi in diverse directory.
-
+
Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
collegamento diretto è possibile solo se entrambi i \itindex{pathname}
\textit{pathname} sono nello stesso filesystem; inoltre il filesystem deve
supportare i collegamenti diretti (il meccanismo non è disponibile ad esempio
-con il filesystem \acr{vfat} di Windows).
+con il filesystem \acr{vfat} di Windows). In realtà la funzione ha un
+ulteriore requisito, e cioè che non solo che i due file siano sullo stesso
+filesystem, ma anche che si faccia riferimento ad essi sullo stesso
+\textit{mount point}.\footnote{si tenga presente infatti (vedi
+ sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno stesso
+ filesystem può essere montato più volte su directory diverse.}
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
Data la pericolosità di questa operazione e la disponibilità dei link
simbolici che possono fornire la stessa funzionalità senza questi problemi,
-nei filesystem usati in Linux questa caratteristica è stata completamente
-disabilitata, e al tentativo di creare un link diretto ad una directory la
-funzione restituisce l'errore \errcode{EPERM}.
+nel caso di Linux questa capacità è stata completamente disabilitata, e al
+tentativo di creare un link diretto ad una directory la funzione \func{link}
+restituisce l'errore \errcode{EPERM}.
+
+Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
+\textit{hard link} ad un link simbolico. In questo caso lo standard POSIX
+prevederebbe che quest'ultimo venga risolto e che il collegamento sia
+effettuato rispetto al file cui esso punta, e che venga riportato un errore
+qualora questo non esista o non sia un file. Questo era anche il comportamento
+iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la
+ precisione il comportamento era quello previsto dallo standard POSIX fino al
+ kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
+ durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento
+ attuale fino ad oggi (per riferimento si veda
+ \href{http://lwn.net/Articles/293902}
+ {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un
+comportamento che non segue più lo standard per cui l'\textit{hard link} viene
+creato rispetto al link simbolico, e non al file cui questo punta.
+
+La ragione di questa differenza rispetto allo standard, presente anche in
+altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
+riferimento anche ad un file non esistente o a una directory, per i quali
+l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
+link simbolico è stata ritenuta una scelta scorretta nella progettazione
+dell'interfaccia. Infatti se non ci fosse il comportamento adottato da Linux
+sarebbe impossibile creare un \textit{hard link} ad un link simbolico, perché
+la funzione lo risolverebbe e l'\textit{hard link} verrebbe creato verso la
+destinazione. Invece evitando di seguire lo standard l'operazione diventa
+possibile, ed anche il comportamento della funzione risulta molto più
+comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
+ link} rispetto alla destinazione di un link simbolico è sempre possibile
+farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
+ standard possa causare problemi, come nell'esempio descritto nell'articolo
+ citato nella nota precedente, a programmi che non si aspettano questa
+ differenza rispetto allo standard POSIX.}
La rimozione di un file (o più precisamente della voce che lo referenzia
all'interno di una directory) si effettua con la funzione \funcd{unlink}; il
abbia privilegi sufficienti.}
La funzione cancella il nome specificato da \param{pathname} nella relativa
-directory e decrementa il numero di riferimenti nel relativo \index{inode}
-inode. Nel caso di link simbolico cancella il link simbolico; nel caso di
-socket, fifo o file di dispositivo \index{file!di~dispositivo} rimuove il
-nome, ma come per i file i processi che hanno aperto uno di questi oggetti
+directory e decrementa il numero di riferimenti nel relativo \itindex{inode}
+\textit{inode}. Nel caso di link simbolico cancella il link simbolico; nel
+caso di socket, fifo o file di dispositivo \index{file!di~dispositivo} rimuove
+il nome, ma come per i file i processi che hanno aperto uno di questi oggetti
possono continuare ad utilizzarlo.
Per cancellare una voce in una directory è necessario avere il permesso di
Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
nome dalla directory e l'incremento/decremento del numero di riferimenti
-\index{inode} nell'inode devono essere effettuati in maniera atomica (si veda
-sez.~\ref{sec:proc_atom_oper}) senza possibili interruzioni fra le due
-operazioni. Per questo entrambe queste funzioni sono realizzate tramite una
-singola system call.
+\itindex{inode} nell'\textit{inode} devono essere effettuati in maniera
+atomica (si veda sez.~\ref{sec:proc_atom_oper}) senza possibili interruzioni
+fra le due operazioni. Per questo entrambe queste funzioni sono realizzate
+tramite una singola system call.
Si ricordi infine che un file non viene eliminato dal disco fintanto che tutti
i riferimenti ad esso sono stati cancellati: solo quando il \textit{link
- count} mantenuto \index{inode} nell'inode diventa zero lo spazio occupato su
-disco viene rimosso (si ricordi comunque che a questo si aggiunge sempre
-un'ulteriore condizione,\footnote{come vedremo in
+ count} mantenuto \itindex{inode} nell'\textit{inode} diventa zero lo spazio
+occupato su disco viene rimosso (si ricordi comunque che a questo si aggiunge
+sempre un'ulteriore condizione,\footnote{come vedremo in
cap.~\ref{cha:file_unix_interface} il kernel mantiene anche una tabella dei
file aperti nei vari processi, che a sua volta contiene i riferimenti agli
- \index{inode} inode ad essi relativi. Prima di procedere alla cancellazione
- dello spazio occupato su disco dal contenuto di un file il kernel controlla
- anche questa tabella, per verificare che anche in essa non ci sia più nessun
- riferimento all'inode in questione.} e cioè che non ci siano processi che
-abbiano il suddetto file aperto).
+ \itindex{inode} \textit{inode} ad essi relativi. Prima di procedere alla
+ cancellazione dello spazio occupato su disco dal contenuto di un file il
+ kernel controlla anche questa tabella, per verificare che anche in essa non
+ ci sia più nessun riferimento all'\textit{inode} in questione.} e cioè che
+non ci siano processi che abbiano il suddetto file aperto).
Questa proprietà viene spesso usata per essere sicuri di non lasciare file
temporanei su disco in caso di crash dei programmi; la tecnica è quella di
\label{sec:file_symlink}
Come abbiamo visto in sez.~\ref{sec:file_link} la funzione \func{link} crea
-riferimenti agli \index{inode} inode, pertanto può funzionare soltanto per file
-che risiedono sullo stesso filesystem e solo per un filesystem di tipo Unix.
-Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto
-ad una directory.
+riferimenti agli \itindex{inode} \textit{inode}, pertanto può funzionare
+soltanto per file che risiedono sullo stesso filesystem e solo per un
+filesystem di tipo Unix. Inoltre abbiamo visto che in Linux non è consentito
+eseguire un link diretto ad una directory.
Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
Il sistema funziona in quanto i link simbolici sono riconosciuti come tali dal
kernel\footnote{è uno dei diversi tipi di file visti in
- tab.~\ref{tab:file_file_types}, contrassegnato come tale nell'inode, e
- riconoscibile dal valore del campo \var{st\_mode} della struttura
- \struct{stat} (vedi sez.~\ref{sec:file_stat}).} per cui alcune funzioni di
-libreria (come \func{open} o \func{stat}) quando ricevono come argomento un
-link simbolico vengono automaticamente applicate al file da esso specificato.
-La funzione che permette di creare un nuovo link simbolico è \funcd{symlink},
-ed il suo prototipo è:
+ tab.~\ref{tab:file_file_types}, contrassegnato come tale
+ nell'\textit{inode}, e riconoscibile dal valore del campo \var{st\_mode}
+ della struttura \struct{stat} (vedi sez.~\ref{sec:file_stat}).} per cui
+alcune funzioni di libreria (come \func{open} o \func{stat}) quando ricevono
+come argomento un link simbolico vengono automaticamente applicate al file da
+esso specificato. La funzione che permette di creare un nuovo link simbolico
+è \funcd{symlink}, ed il suo prototipo è:
\begin{prototype}{unistd.h}
{int symlink(const char *oldpath, const char *newpath)}
Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
\func{chown} & -- & $\bullet$ \\
\func{creat} & $\bullet$ & -- \\
\func{exec} & $\bullet$ & -- \\
- \func{lchown} & $\bullet$ & $\bullet$ \\
- \func{link} & -- & -- \\
+ \func{lchown} & $\bullet$ & -- \\
+ \func{link}\footnotemark & -- & $\bullet$ \\
\func{lstat} & -- & $\bullet$ \\
\func{mkdir} & $\bullet$ & -- \\
\func{mkfifo} & $\bullet$ & -- \\
\label{tab:file_symb_effect}
\end{table}
+\footnotetext{a partire dalla serie 2.0, e contrariamente a quanto indicato
+ dallo standard POSIX, si veda quanto detto in sez.~\ref{sec:file_link}.}
+
Si noti che non si è specificato il comportamento delle funzioni che operano
con i file descriptor, in quanto la risoluzione del link simbolico viene in
genere effettuata dalla funzione che restituisce il file descriptor
\label{sec:file_dir_creat_rem}
Benché in sostanza le directory non siano altro che dei file contenenti
-elenchi di nomi ed \index{inode} inode, non è possibile trattarle come file
-ordinari e devono essere create direttamente dal kernel attraverso una
-opportuna system call.\footnote{questo è quello che permette anche, attraverso
- l'uso del VFS, l'utilizzo di diversi formati per la gestione dei suddetti
- elenchi.} La funzione usata per creare una directory è \funcd{mkdir}, ed il
-suo prototipo è:
+elenchi di nomi ed \itindex{inode} \textit{inode}, non è possibile trattarle
+come file ordinari e devono essere create direttamente dal kernel attraverso
+una opportuna system call.\footnote{questo è quello che permette anche,
+ attraverso l'uso del VFS, l'utilizzo di diversi formati per la gestione dei
+ suddetti elenchi.} La funzione usata per creare una directory è
+\funcd{mkdir}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/stat.h}
\headdecl{sys/types.h}
\textit{pathname} assoluto o relativo.
La modalità con cui avviene la cancellazione è analoga a quella di
-\func{unlink}: fintanto che il numero di link \index{inode} all'inode della
-directory non diventa nullo e nessun processo ha la directory aperta lo spazio
-occupato su disco non viene rilasciato. Se un processo ha la directory aperta
-la funzione rimuove il link \index{inode} all'inode e nel caso sia l'ultimo,
-pure le voci standard ``\file{.}'' e ``\file{..}'', a questo punto il kernel
-non consentirà di creare più nuovi file nella directory.
+\func{unlink}: fintanto che il numero di link \itindex{inode}
+all'\textit{inode} della directory non diventa nullo e nessun processo ha la
+directory aperta lo spazio occupato su disco non viene rilasciato. Se un
+processo ha la directory aperta la funzione rimuove il link \itindex{inode}
+all'\textit{inode} e nel caso sia l'ultimo, pure le voci standard ``\file{.}''
+e ``\file{..}'', a questo punto il kernel non consentirà di creare più nuovi
+file nella directory.
\subsection{La creazione di file speciali}
\headdecl{unistd.h}
\funcdecl{int mknod(const char *pathname, mode\_t mode, dev\_t dev)}
- Crea un inode, si usa per creare i file speciali.
+ Crea un \textit{inode} del tipo specificato sul filesystem.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare l'inode, o
- il filesystem su cui si è cercato di creare \param{pathname} non supporta
- l'operazione.
+ \item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare
+ l'\texttt{inode}, o il filesystem su cui si è cercato di
+ creare \param{pathname} non supporta l'operazione.
\item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
- fifo o un dispositivo.
+ fifo, un socket o un dispositivo.
\item[\errcode{EEXIST}] \param{pathname} esiste già o è un link simbolico.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
Per il tipo di file può essere specificato solo uno fra: \const{S\_IFREG} per
un file regolare (che sarà creato vuoto), \const{S\_IFBLK} per un dispositivo
-a blocchi, \const{S\_IFCHR} per un dispositivo a caratteri e \const{S\_IFIFO}
-per una fifo. Un valore diverso comporterà l'errore \errcode{EINVAL}. Qualora
-si sia specificato in \param{mode} un file di dispositivo, il valore di
-\param{dev} viene usato per indicare a quale dispositivo si fa riferimento.
-
-Solo l'amministratore può creare un file di dispositivo o un file regolare
-usando questa funzione; ma in Linux\footnote{la funzione non è prevista dallo
- standard POSIX, e deriva da SVr4, con appunto questa differenza e diversi
- codici di errore.} l'uso per la creazione di una fifo è consentito anche
-agli utenti normali.
-
-I nuovi \index{inode} inode creati con \func{mknod} apparterranno al
-proprietario e al gruppo del processo che li ha creati, a meno che non si sia
-attivato il bit \acr{sgid} per la directory o sia stata attivata la semantica
-BSD per il filesystem (si veda sez.~\ref{sec:file_ownership_management}) in
-cui si va a creare \index{inode} l'inode.
+a blocchi, \const{S\_IFCHR} per un dispositivo a caratteri, \const{S\_IFSOCK}
+e \const{S\_IFIFO} per una fifo. Un valore diverso comporterà l'errore
+\errcode{EINVAL}. Qualora si sia specificato in \param{mode} un file di
+dispositivo (\const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev}
+dovrà essere usato per indicare a quale dispositivo si fa riferimento con il
+relativo numero.
+
+Solo l'amministratore può creare un file di dispositivo usando questa funzione
+(il processo deve avere la \textit{capability} \const{CAP\_MKNOD}); ma in
+Linux\footnote{la funzione non è prevista dallo standard POSIX, e deriva da
+ SVr4, con appunto questa differenza e diversi codici di errore.} l'uso per
+la creazione di un file ordinario, di una fifo o di un socket è consentito
+anche agli utenti normali.
+
+I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno
+al proprietario e al gruppo del processo che li ha creati, a meno che non si
+sia attivato il bit \acr{sgid} per la directory o sia stata attivata la
+semantica BSD per il filesystem (si veda
+sez.~\ref{sec:file_ownership_management}) in cui si va a creare
+\itindex{inode} l'\textit{inode}.
Per creare una fifo (un file speciale, su cui torneremo in dettaglio in
sez.~\ref{sec:ipc_named_pipe}) lo standard POSIX specifica l'uso della funzione
\label{sec:file_dir_read}
Benché le directory alla fine non siano altro che dei file che contengono
-delle liste di nomi ed \index{inode} inode, per il ruolo che rivestono nella
-struttura del sistema, non possono essere trattate come dei normali file di
-dati. Ad esempio, onde evitare inconsistenze all'interno del filesystem, solo
-il kernel può scrivere il contenuto di una directory, e non può essere un
-processo a inserirvi direttamente delle voci con le usuali funzioni di
-scrittura.
+delle liste di nomi ed \itindex{inode} \textit{inode}, per il ruolo che
+rivestono nella struttura del sistema, non possono essere trattate come dei
+normali file di dati. Ad esempio, onde evitare inconsistenze all'interno del
+filesystem, solo il kernel può scrivere il contenuto di una directory, e non
+può essere un processo a inserirvi direttamente delle voci con le usuali
+funzioni di scrittura.
Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
kernel, sono molte le situazioni in cui i processi necessitano di poterne
una lunghezza, ma solo un limite \const{NAME\_MAX}; in SVr4 la lunghezza del
campo è definita come \code{NAME\_MAX+1} che di norma porta al valore di 256
byte usato anche in Linux.} ed il campo \var{d\_ino}, che contiene il numero
-di \index{inode} inode cui il file è associato (di solito corrisponde al campo
-\var{st\_ino} di \struct{stat}).
+di \itindex{inode} \textit{inode} cui il file è associato (di solito
+corrisponde al campo \var{st\_ino} di \struct{stat}).
\begin{figure}[!htb]
\footnotesize \centering
sez.~\ref{sec:proc_fork}), la directory corrente della shell diventa anche la
directory corrente di qualunque comando da essa lanciato.
-In genere il kernel tiene traccia per ciascun processo \index{inode}
-dell'inode della directory di lavoro, per ottenere il \textit{pathname}
-occorre usare una apposita funzione di libreria, \funcd{getcwd}, il cui
-prototipo è:
+In genere il kernel tiene traccia per ciascun processo \itindex{inode}
+dell'\textit{inode} della directory di lavoro, per ottenere il
+\textit{pathname} occorre usare una apposita funzione di libreria,
+\funcd{getcwd}, il cui prototipo è:
\begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}
Legge il \textit{pathname} della directory di lavoro corrente.
Come spiegato in sez.~\ref{sec:file_filesystem} tutte le informazioni generali
relative alle caratteristiche di ciascun file, a partire dalle informazioni
-relative al controllo di accesso, sono mantenute \index{inode} nell'inode.
+relative al controllo di accesso, sono mantenute \itindex{inode}
+nell'\textit{inode}.
Vedremo in questa sezione come sia possibile leggere tutte queste informazioni
usando la funzione \func{stat}, che permette l'accesso a tutti i dati
-memorizzati \index{inode} nell'inode; esamineremo poi le varie funzioni usate
-per manipolare tutte queste informazioni (eccetto quelle che riguardano la
-gestione del controllo di accesso, trattate in in
+memorizzati \itindex{inode} nell'\textit{inode}; esamineremo poi le varie
+funzioni usate per manipolare tutte queste informazioni (eccetto quelle che
+riguardano la gestione del controllo di accesso, trattate in in
sez.~\ref{sec:file_access_control}).
\label{sec:file_file_times}
Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
-\index{inode} nell'inode insieme agli altri attributi del file e possono
-essere letti tramite la funzione \func{stat}, che li restituisce attraverso
-tre campi della struttura \struct{stat} di fig.~\ref{fig:file_stat_struct}. Il
-significato di detti tempi e dei relativi campi è riportato nello schema in
-tab.~\ref{tab:file_file_times}, dove è anche riportato un esempio delle
-funzioni che effettuano cambiamenti su di essi.
+\itindex{inode} nell'\textit{inode} insieme agli altri attributi del file e
+possono essere letti tramite la funzione \func{stat}, che li restituisce
+attraverso tre campi della struttura \struct{stat} di
+fig.~\ref{fig:file_stat_struct}. Il significato di detti tempi e dei relativi
+campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche
+riportato un esempio delle funzioni che effettuano cambiamenti su di essi.
\begin{table}[htb]
\centering
\func{read}, \func{utime} & \cmd{-u}\\
\var{st\_mtime}& ultima modifica ai dati del file &
\func{write}, \func{utime} & default\\
- \var{st\_ctime}& ultima modifica ai dati dell'inode &
+ \var{st\_ctime}& ultima modifica ai dati dell'\textit{inode} &
\func{chmod}, \func{utime} & \cmd{-c}\\
\hline
\end{tabular}
modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di
cambiamento di stato (il \textit{change time} \var{st\_ctime}). Il primo
infatti fa riferimento ad una modifica del contenuto di un file, mentre il
-secondo ad una modifica \index{inode} dell'inode; siccome esistono molte
-operazioni (come la funzione \func{link} e molte altre che vedremo in seguito)
-che modificano solo le informazioni contenute \index{inode} nell'inode senza
-toccare il contenuto del file, diventa necessario l'utilizzo di un altro
-tempo.
-
-Il sistema non tiene conto dell'ultimo accesso \index{inode} all'inode,
-pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza
-sui tre tempi. Il tempo di ultimo accesso (ai dati) viene di solito usato per
-cancellare i file che non servono più dopo un certo lasso di tempo (ad esempio
-il programma \cmd{leafnode} cancella i vecchi articoli sulla base di questo
-tempo).
+secondo ad una modifica \itindex{inode} dell'\textit{inode}; siccome esistono
+molte operazioni (come la funzione \func{link} e molte altre che vedremo in
+seguito) che modificano solo le informazioni contenute \itindex{inode}
+nell'\textit{inode} senza toccare il contenuto del file, diventa necessario
+l'utilizzo di un altro tempo.
+
+Il sistema non tiene conto dell'ultimo accesso \itindex{inode}
+all'\textit{inode}, pertanto funzioni come \func{access} o \func{stat} non
+hanno alcuna influenza sui tre tempi. Il tempo di ultimo accesso (ai dati)
+viene di solito usato per cancellare i file che non servono più dopo un certo
+lasso di tempo (ad esempio il programma \cmd{leafnode} cancella i vecchi
+articoli sulla base di questo tempo).
\begin{table}[htb]
\centering
\begin{prototype}{utime.h}
{int utime(const char *filename, struct utimbuf *times)}
-Cambia i tempi di ultimo accesso e modifica \index{inode} dell'inode
-specificato da \param{filename} secondo i campi \var{actime} e \var{modtime}
-di \param{times}. Se questa è \val{NULL} allora viene usato il tempo corrente.
+Cambia i tempi di ultimo accesso e modifica \itindex{inode}
+dell'\textit{inode} specificato da \param{filename} secondo i campi
+\var{actime} e \var{modtime} di \param{times}. Se questa è \val{NULL} allora
+viene usato il tempo corrente.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
Si tenga presente che non è comunque possibile specificare il tempo di
cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
-volte che si modifica \index{inode} l'inode (quindi anche alla chiamata di
-\func{utime}). Questo serve anche come misura di sicurezza per evitare che si
-possa modificare un file nascondendo completamente le proprie tracce. In
-realtà la cosa resta possibile, se si è in grado di accedere al file di
-dispositivo, scrivendo direttamente sul disco senza passare attraverso il
-filesystem, ma ovviamente in questo modo la cosa è molto più complicata da
+volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche alla
+chiamata di \func{utime}). Questo serve anche come misura di sicurezza per
+evitare che si possa modificare un file nascondendo completamente le proprie
+tracce. In realtà la cosa resta possibile, se si è in grado di accedere al
+file di dispositivo, scrivendo direttamente sul disco senza passare attraverso
+il filesystem, ma ovviamente in questo modo la cosa è molto più complicata da
realizzare.
riportato in fig.~\ref{fig:file_perm_bit}.
Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
-memorizzati \index{inode} nell'inode; in particolare essi sono contenuti in
-alcuni bit del campo \var{st\_mode} della struttura \struct{stat} (si veda di
-nuovo fig.~\ref{fig:file_stat_struct}).
+memorizzati \itindex{inode} nell'\textit{inode}; in particolare essi sono
+contenuti in alcuni bit del campo \var{st\_mode} della struttura \struct{stat}
+(si veda di nuovo fig.~\ref{fig:file_stat_struct}).
In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
\cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o} (per
\itindbeg{Extended~Attributes}
Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
-che il sistema mantiene negli inode, e le varie funzioni che permettono di
-modificarle. Si sarà notato come in realtà queste informazioni siano
-estremamente ridotte. Questo è dovuto al fatto che Unix origina negli anni
-'70, quando le risorse di calcolo e di spazio disco erano minime. Con il venir
-meno di queste restrizioni è incominciata ad emergere l'esigenza di poter
-associare ai file delle ulteriori informazioni astratte (quelli che vengono
-chiamati i \textsl{meta-dati}) che però non potevano trovare spazio nei dati
-classici mantenuti negli inode.
+che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie
+funzioni che permettono di modificarle. Si sarà notato come in realtà queste
+informazioni siano estremamente ridotte. Questo è dovuto al fatto che Unix
+origina negli anni '70, quando le risorse di calcolo e di spazio disco erano
+minime. Con il venir meno di queste restrizioni è incominciata ad emergere
+l'esigenza di poter associare ai file delle ulteriori informazioni astratte
+(quelli che vengono chiamati i \textsl{meta-dati}) che però non potevano
+trovare spazio nei dati classici mantenuti negli \itindex{inode}
+\textit{inode}.
Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
Linux) hanno introdotto un meccanismo generico che consenta di associare delle
richiedono una gran numero di accessi, come le ACL.} e di garantire
l'atomicità di tutte le operazioni.
-In Linux gli attributi estesi sono sempre associati al singolo inode e
-l'accesso viene sempre eseguito in forma atomica, in lettura il valore
-corrente viene scritto su un buffer in memoria, mentre la scrittura prevede
-che ogni valore precedente sia sovrascritto.
+In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode}
+\textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura
+il valore corrente viene scritto su un buffer in memoria, mentre la scrittura
+prevede che ogni valore precedente sia sovrascritto.
Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
Attributes}, in particolare al momento della scrittura di queste dispense
all'interno di un singolo blocco (pertanto con dimensioni massime pari a
1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono
- limiti ed i dati vengono memorizzati in maniera diversa (nell'inode stesso,
- in un blocco a parte, o in una struttura ad albero dedicata) per mantenerne
- la scalabilità.} Infine lo spazio utilizzato per mantenere gli attributi
-estesi viene tenuto in conto per il calcolo delle quote di utente e gruppo
-proprietari del file.
+ limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode}
+ stesso, in un blocco a parte, o in una struttura ad albero dedicata) per
+ mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
+attributi estesi viene tenuto in conto per il calcolo delle quote di utente e
+gruppo proprietari del file.
Come meccanismo per mantenere informazioni aggiuntive associate al singolo
file, gli \textit{Extended Attributes} possono avere usi anche molto diversi
permessi iniziale.} in tal caso saranno eliminati dalle voci corrispondenti
nella ACL tutti quelli non presenti in tale indicazione.
-Dato che questa è la ragione che ha portato alla loro creazione, la pricipale
+Dato che questa è la ragione che ha portato alla loro creazione, la principale
modifica introdotta con la presenza della ACL è quella alle regole del
controllo di accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}.
Come nel caso ordinario per il controllo vengono sempre utilizzati gli
Una volta che si siano completate le operazioni sui dati di una ACL la memoria
allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
-funzione \funcd{acl\_free}, il cui protipo è:
+funzione \funcd{acl\_free}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\end{table}
Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
-processo chiamante abbia privilegi di accesso sufficenti a poter leggere gli
+processo chiamante abbia privilegi di accesso sufficienti a poter leggere gli
attributi estesi dei file (come illustrati in sez.~\ref{sec:file_xattr});
inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta
soltanto per una directory, e verrà restituita solo se presente, altrimenti
contenente la rappresentazione in forma estesa della ACL passata come
argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
essere liberata, quando non più necessaria, con \func{acl\_free}. Se
-nell'argomento \param{len\_p} si passa un valore puntatote ad una variabile
+nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
intera in questa verrà restituita la dimensione della stringa con la
rappresentazione testuale (non comprendente il carattere nullo finale).
% LocalWords: un'etichetta int const char oldpath newpath errno EXDEV EPERM st
% LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls
% LocalWords: ELOOP ENOSPC EIO pathname nlink stat vfat fsck EISDIR ENOENT cap
-% LocalWords: POSIX socket fifo sticky root nell'inode system call count crash
-% LocalWords: all'inode descriptor remove rename rmdir stdio glibc libc NFS DT
+% LocalWords: POSIX socket fifo sticky root system call count crash nell' init
+% LocalWords: descriptor remove rename rmdir stdio glibc libc NFS DT obj dup
% LocalWords: ENOTEMPTY EBUSY mount point EINVAL soft symbolic tab symlink fig
% LocalWords: dangling access chdir chmod chown creat exec lchown lstat mkdir
% LocalWords: mkfifo mknod opendir pathconf readlink truncate path buff size
% LocalWords: grub bootloader grep linux MAXSYMLINKS cat VFS sys dirname fcntl
-% LocalWords: dev l'inode umask IFREG IFBLK IFCHR IFIFO SVr sgid BSD SVID NULL
+% LocalWords: dev umask IFREG IFBLK IFCHR IFIFO SVr sgid BSD SVID NULL from to
% LocalWords: stream dirent EMFILE ENFILE dirfd SOURCE fchdir readdir struct
% LocalWords: EBADF namlen HAVE thread entry result value argument fileno ino
% LocalWords: name TYPE OFF RECLEN UNKNOWN REG SOCK CHR BLK type IFTODT DTTOIF
% LocalWords: DTYPE off reclen seekdir telldir void rewinddir closedir select
% LocalWords: namelist compar malloc qsort alphasort versionsort strcoll myls
% LocalWords: strcmp DirScan direntry while current working home shell pwd get
-% LocalWords: dell'inode getcwd ERANGE getwd change fd race condition tmpnam
+% LocalWords: getcwd ERANGE getwd change fd race condition tmpnam getfacl mark
% LocalWords: string tmpdir TMP tempnam pfx TMPNAME suid tmp EXCL tmpfile pid
% LocalWords: EINTR mktemp mkstemp stlib template filename XXXXXX OpenBSD buf
% LocalWords: mkdtemp fstat filedes nell'header padding ISREG ISDIR ISCHR IFMT
% LocalWords: fgetxattr attr ssize ENOATTR ENOTSUP NUL setxattr lsetxattr list
% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by
% LocalWords: removexattr lremovexattr fremovexattr attributename lacl acl
-% LocalWords: OBJ
+% LocalWords: OBJ setfacl len any prefix separator options NUMERIC IDS SMART
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: INDENT
projects / gapil.git / commitdiff