Rimesse a posto un sacco di referenze, figure, etc.
[gapil.git] / filedir.tex
index 4c2f8d147272f58edbbe6f455b4408bfb2cebb30..c071ecaac899423d1b984aa7eb60bcb347a8049e 100644 (file)
@@ -13,7 +13,7 @@ dei file 
 
 Le prime funzioni che considereremo sono quelle relative alla gestione di file
 e directory, secondo le caratteristiche standard che essi presentano in un
-filesystem unix, già esaminate in precedenza (vedi
+filesystem unix, la cui struttura abbiamo esaminato in precedenza (vedi
 \secref{sec:fileintr_filesystem}).
 
 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
@@ -89,14 +89,14 @@ filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non 
 il caso ad esempio del filesystem \texttt{vfat} di windows).
 
 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
-ma solo l'amministratore è in grado di creare un collegamento diretto ad
-un'altra directory, questo lo si fa perché in questo caso è possibile creare
-dei circoli nel filesystem (vedi \secref{sec:fileintr_symlink}) che molti
-programmi non sono in grado di gestire e la cui rimozione diventa estremamente
-complicata (in genere occorre far girare il programma \texttt{fsck} per
-riparare il filesystem); data la sua pericolosità in Linux questa
-caratteristica è stata disabilitata, e la funzione restituisce l'errore
-\texttt{EPERM}.
+in alcuni filesystem solo l'amministratore è in grado di creare un
+collegamento diretto ad un'altra directory, questo lo si fa perché in questo
+caso è possibile creare dei circoli nel filesystem (vedi
+\secref{sec:fileintr_symlink}) che molti programmi non sono in grado di
+gestire e la cui rimozione diventa estremamente complicata (in genere occorre
+far girare il programma \texttt{fsck} per riparare il filesystem); data la sua
+pericolosità in generale nei filesystem usati in Linux questa caratteristica è
+stata disabilitata, e la funzione restituisce l'errore \texttt{EPERM}.
 
 La rimozione di un file (o più precisamente della voce che lo referenzia) si
 effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
@@ -255,10 +255,10 @@ al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
 lettura del contenuto del medesimo e l'applicazione della funzione al file
 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
-o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
-funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
-alle informazioni del link invece che a quelle del file a cui esso fa
-riferimento.
+o rinominare i file operano direttamente sul link simbolico (per l'elenco vedi
+\ntab). Inoltre esistono funzioni apposite, come la \texttt{readlink} e la
+\texttt{lstat} per accedere alle informazioni del link invece che a quelle del
+file a cui esso fa riferimento.
 
 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
 dichiarate nell'header file \texttt{unistd.h}.
@@ -310,6 +310,87 @@ questa funzione 
   \end{errlist}
 \end{prototype}
 
+In \ntab\ si è riportato un elenco dei comportamenti delle varie funzioni che
+operano sui file rispetto ai link simbolici; specificando quali seguono il
+link simbolico e quali possono operare direttamente sul suo contenuto.
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|c|c|}
+    \hline
+    Funzione & Segue il link & Non segue il link \\
+    \hline 
+    \hline 
+    \func{access}   & $\bullet$ &           \\
+    \func{chdir}    & $\bullet$ &           \\
+    \func{chmod}    & $\bullet$ &           \\
+    \func{chown}    &           & $\bullet$ \\
+    \func{creat}    & $\bullet$ &           \\
+    \func{exec}     & $\bullet$ &           \\
+    \func{lchown}   & $\bullet$ & $\bullet$ \\
+    \func{link}     &           &           \\
+    \func{lstat}    &           & $\bullet$ \\
+    \func{mkdir}    & $\bullet$ &           \\
+    \func{mkfifo}   & $\bullet$ &           \\
+    \func{mknod}    & $\bullet$ &           \\
+    \func{open}     & $\bullet$ &           \\
+    \func{opendir}  & $\bullet$ &           \\
+    \func{pathconf} & $\bullet$ &           \\
+    \func{readlink} &           & $\bullet$ \\
+    \func{remove}   &           & $\bullet$ \\
+    \func{rename}   &           & $\bullet$ \\
+    \func{stat}     & $\bullet$ &           \\
+    \func{truncate} & $\bullet$ &           \\
+    \func{unlink}   &           & $\bullet$ \\
+    \hline 
+  \end{tabular}
+  \caption{Uso dei link simbolici da parte di alcune funzioni.}
+  \label{tab:filedir_symb_effect}
+\end{table}
+si noti che non si è specificato il comportamento delle funzioni che operano
+con i file descriptor, in quanto la gestione del link simbolico viene in
+genere effttuata dalla funzione che restituisce il file descriptor
+(normalmente la \func{open}).
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=5cm]{img/link_loop.eps}
+  \caption{Esempio di loop nel filesystem creato con un link simbolico.}
+  \label{fig:filedir_link_loop}
+\end{figure}
+
+Un caso comune che si può avere con i link simbolici è la creazione dei
+cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta
+la struttura della directory \file{/boot}. Come si vede si è creato al suo
+interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
+  tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
+  bootloader estremamente avanzato in grado di accedere direttamente
+  attraverso vari filesystem al file da lanciare come sistema operativo) di
+  vedere i file in questa directory, che è montata su una partizione separata
+  (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
+  visti dal sistema operativo.}. 
+
+Questo può causare problemi per tutti quei programmi che effettuassero uno
+scan di una directory senza tener conto dei link simbolici, in quel caso
+infatti il loop nella directory 
+
+Un secondo punto da tenere presente è che un link simbolico può essere fatto
+anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
+nella nostra directory con un link del tipo:
+\begin{verbatim}
+$ln -s /tmp/tmp_file temporaneo
+\end{verbatim}%$
+ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura
+\file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola
+lettura (ad esempio con \cmd{cat}) otterremmo:
+\begin{verbatim}
+$ cat prova 
+cat: prova: No such file or directory
+\end{verbatim}%$
+con un errore che sembra sbagliato, dato \cmd{ls} ci mostrerebbe l'esistenza
+di \file{temporaneo}.
+
+
 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} 
 \label{sec:filedir_dir_creat_rem}
 
@@ -502,7 +583,7 @@ riservati per estensioni come tempi pi
   \footnotesize
   \centering
   \begin{minipage}[c]{15cm}
-    \begin{lstlisting}[]{}
+    \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 struct stat {
     dev_t         st_dev;      /* device */
     ino_t         st_ino;      /* inode */
@@ -608,20 +689,27 @@ per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in
 
 Il primo valore definisce la maschera dei bit usati nei quali viene
 memorizzato il tipo di files, mentre gli altri possono essere usati per
-effettuare delle selezioni sul tipo di file voluto.
+effettuare delle selezioni sul tipo di file voluto, combinando opportunamente
+i vari flag; ad esempio se si volesse controllare se un file è una directory o
+un file ordinario si potrebbe definire la condizione:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+#define IS_FILE_DIR(x) ( ((x) & S_IFMT) & (S_IFDIR | S_IFREG) )
+\end{lstlisting}
+in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
+poi si effettua il confronto con la combinazione di tipi scelta.
 
 \subsection{La dimensione dei file}
 \label{sec:filedir_file_size}
 
 Il membro \var{st\_size} contiene la dimensione del file in bytes (se il file
 è un file normale, nel caso di un link simbolico al dimensione è quella del
-pathname che contiene, per le directory è in genere un multiplo di 512). 
+pathname che contiene). 
 
 Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
 bytes. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
 i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
-per l'interfaccia deglli stream); scrivere in blocchi di dimensione inferiore
-sarebbe inefficiente.
+per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
+dimensione inferiore sarebbe inefficiente.
 
 Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
 che corrisponda all'occupazione dello spazio su disco per via della possibile
@@ -637,7 +725,6 @@ legge dal file (ad esempio usando \cmd{wc -c}), dato che in tal caso per le
 parti non scritte vengono restituiti degli zeri, si avrà lo stesso risultato
 di \cmd{ls}.
 
-
 Se è sempre possibile allargare un file scrivendoci sopra od usando la
 funzione \func{seek} per spostarsi oltre la sua fine. Esistono però anche casi
 in cui si può avere bisogno di effettuare un troncamento scartando i dati al
@@ -647,11 +734,11 @@ Un file pu
 questo è un caso particolare; per qualunque altra dimensione si possono usare
 le due funzioni:
 \begin{functions}
-  \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off_t
+  \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
     length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad
     un valore massimo specificato da \var{lenght}. 
   
-  \funcdecl{int ftruncate(int fd, off_t length))} Identica a \func{truncate}
+  \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate}
   eccetto che si usa con un file aperto, specificato tramite il suo file
   descriptor \var{fd}, 
   
@@ -672,38 +759,188 @@ le due funzioni:
 
 Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
 perduti; il comportamento in caso di lunghezza inferiore non è specificato e
-dipende dall'implementazione, il file può essere lasciato invariato o esteso
+dipende dall'implementazione: il file può essere lasciato invariato o esteso
 fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con
 zeri (e in genere si ha la creazione di un hole nel file).
 
 \subsection{I tempi dei file}
 \label{sec:filedir_file_times}
 
-Il sistema mantiene tre tempi per ciascun file, corrispondenti a tre campi
-della struttura \func{stat}, come riassunto in \ntab:
+Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
+nell'inode insieme agli altri attibuti del file e possono essere letti tramite
+la funzione \func{stat}, che li restituisce attraverso tre campi della
+struttura in \figref{fig:filedir_stat_struct}. Il significato di detti tempi e
+dei relativi campi è riportato nello schema in \ntab:
 
 \begin{table}[htb]
   \centering
   \begin{tabular}[c]{|c|l|l|c|}
-    \var{st\_atime} & & &   \\ 
-    \var{st\_mtime} & & &   \\ 
-    \var{st\_ctime} & & &   \\ 
+    \hline
+    Membro & Significato & Funzione&opzione \\
+    \hline
+    \hline
+    \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\ 
+    \var{st\_mtime}& ultima modifica ai dati del file &\func{write}& default\\ 
+    \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod}, 
+    \func{utime} & \cmd{-c} \\ 
+    \hline
   \end{tabular}
   \caption{I tre tempi associati a ciascun file}
   \label{tab:filedir_file_times}
 \end{table}
 
+Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
+modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di
+cambiamento di stato (il \textit{chage time} \var{st\_ctime}). Il primo
+infatti fa riferimento ad una modifica del contenuto di un file, mentre il
+secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la
+funzione \func{link} e molte altre che vedremo in seguito) che modificano solo
+le informazioni contenute nell'inode senza toccare il file, diventa necessario
+l'utilizzo di un altro tempo.
+
+Il sistema non tiene conto dell'ultimo accesso all'inode, pertanto funzioni
+come \func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il
+tempo di ultimo accesso viene di solito usato per cancellare i file che non
+servono più dopo un certo lasso di tempo (ad esempio \cmd{leafnode} cancella i
+vecchi articoli sulla base di questo tempo).  
+
+Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere
+quali file necessitano di essere ricompilati o (talvolta insieme anche al
+tempo di cambiamento di stato) per decidere quali file devono essere
+archiviati per il backup. 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 \curtab.
+
+L'effetto delle varie funzioni di manipolazione dei file sui tempi è
+illustrato in \ntab. Si sono riportati gli effetti sia per il file a cui si fa
+riferimento, sia per la directory che lo contiene; questi ultimi possono
+essere capiti se si tiene conto di quanto già detto, e cioè che anche le
+directory sono files, che il sistema tratta in maniera del tutto analoga agli
+altri. 
+
+Per questo motivo tutte le volte che compiremo una operazione su un file che
+comporta una modifica della sua directory entry, andremo anche a scrivere
+sulla directory che lo contiene cambiandone il tempo di modifica. Un esempio
+di questo può essere la cancellazione di un file, mentre leggere o scrivere o
+cambiarne i permessi ha effetti solo sui tempi del file.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
+    \hline
+    \multicolumn{1}{|c|}{Funzione} 
+    &\multicolumn{3}{p{2cm}}{File o directory di riferimento}
+    &\multicolumn{3}{p{2cm}}{Directory genitrice del riferimento} 
+    &\multicolumn{1}{|c|}{Note} \\
+    \cline{2-7}
+    &  \textsl{(a)} &  \textsl{(m)}&  \textsl{(c)} 
+    &  \textsl{(a)} &  \textsl{(m)}&  \textsl{(c)}& \\
+    \hline
+    \hline
+    \func{chmod}, \func{fchmod} 
+    &         &         &$\bullet$&         &         &         & \\
+    \func{chown}, \func{fchown} 
+    &         &         &$\bullet$&         &         &         & \\
+    \func{creat}  
+    &$\bullet$&$\bullet$&$\bullet$&         &$\bullet$&$\bullet$&  con 
+    \macro{O\_CREATE} \\    \func{creat}  
+    &         &$\bullet$&$\bullet$&         &$\bullet$&$\bullet$&   
+    con \macro{O\_TRUNC} \\    \func{exec}  
+    &$\bullet$&         &         &         &         &         & \\
+    \func{lchown}  
+    &         &         &$\bullet$&         &         &         & \\
+    \func{link}
+    &         &         &$\bullet$&         &$\bullet$&$\bullet$& \\
+    \func{mkdir}
+    &$\bullet$&$\bullet$&$\bullet$&         &$\bullet$&$\bullet$& \\
+    \func{mkfifo}
+    &$\bullet$&$\bullet$&$\bullet$&         &$\bullet$&$\bullet$& \\
+    \func{open}
+    &$\bullet$&$\bullet$&$\bullet$&         &$\bullet$&$\bullet$& con 
+    \macro{O\_CREATE} \\    \func{open}
+    &         &$\bullet$&$\bullet$&         &         &         & con 
+    \macro{O\_TRUNC}  \\    \func{pipe}
+    &$\bullet$&$\bullet$&$\bullet$&         &         &         & \\
+    \func{read}
+    &$\bullet$&         &         &         &         &         & \\
+    \func{remove}
+    &         &         &$\bullet$&         &$\bullet$&$\bullet$& using 
+    \func{unlink}\\    \func{remove}
+    &         &         &         &         &$\bullet$&$\bullet$& using 
+    \func{rmdir}\\ \func{rename}
+    &         &         &$\bullet$&         &$\bullet$&$\bullet$& per entrambi
+    gli argomenti\\ \func{rmdir}
+    &         &         &         &         &$\bullet$&$\bullet$& \\ 
+    \func{truncate}, \func{ftruncate}
+    &         &$\bullet$&$\bullet$&         &         &         & \\ 
+    \func{unlink}
+    &         &         &$\bullet$&         &$\bullet$&$\bullet$& \\ 
+    \func{utime}
+    &$\bullet$&$\bullet$&$\bullet$&         &         &         & \\ 
+    \func{write}
+    &         &$\bullet$&$\bullet$&         &         &         & \\ 
+    \hline
+  \end{tabular}
+  \caption{Effetti delle varie funzioni su tempi di ultimo accesso 
+    \textsl{(a)}, ultima modifica \textsl{(m)}  e ultimo cambiamento
+    \textsl{(c)}}
+  \label{tab:filedir_times_effects}  
+\end{table}
+
+Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
+creazione del file usato da molti altri sistemi operativi, che in unix non
+esiste.
+
 
 \subsection{La funzione \texttt{utime}}
 \label{sec:filedir_utime}
 
+I tempi di ultimo accesso e modifica possono essere cambiati usando la
+funzione \func{utime}, il cui prototipo è:
 
+\begin{prototype}{utime.h}
+{int utime(const char * filename, struct utimbuf *times)} 
+
+Cambia i tempi di ultimo accesso e modifica dell'inode specificato da
+\var{filename} secondo i campi \var{actime} e \var{modtime} di \var{times}. Se
+questa è \macro{NULL} allora viene usato il tempo corrente.
+
+La funzione restituisce zero in caso di successo e -1 in caso di errore, nel
+qual caso \var{errno} è settata opportunamente.
+\begin{errlist}
+\item \texttt{EACCESS} non si ha il permesso di scrittura sul file.
+\item \texttt{ENOENT} \var{filename} non esiste.
+\end{errlist}
+\end{prototype}
+La struttura \var{utimebuf} usata da \func{utime} è definita come:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+struct utimbuf {
+        time_t actime;  /* access time */
+        time_t modtime; /* modification time */
+};
+\end{lstlisting}
+
+L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
+cosa è l'argomento \var{times}; se è \textit{NULL} la funzione setta il tempo
+corrente ed è sufficiente avere accesso in scrittura al file; se invece si è
+specificato un valore la funzione avrà successo solo se si è proprietari del
+file (o si hanno i privilegi di amministratore).
+
+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 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 device, scrivendo
+direttamente sul disco senza passare attraverso il filesystem, ma ovviamente è
+molto più complicato da realizzare.
 
 
 \section{Il controllo di accesso ai file}
 \label{sec:filedir_access_control}
 
-
 In unix è implementata da qualunque filesystem standard una forma elementare
 (ma adatta alla maggior parte delle esigenze) di controllo di accesso ai
 files. Torneremo sull'argomento in dettaglio più avanti (vedi
@@ -745,8 +982,6 @@ pertanto accesso senza restrizione a qualunque file del sistema.
 % elementare qui; inoltre ad un processo sono associati diversi identificatori,
 % torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}.
 
-
-
 \subsection{I flag \texttt{suid} e \texttt{sgid}}
 \label{sec:filedir_suid_sgid}