Molte correzioni a giro e un po' di roba in piu` sui file.

diff --git a/filedir.tex b/filedir.tex
index 3b13ce8cbf633e3191f5cfcf25e7ee2e72c68f6a..0c06fb26974db6e1d41aba5629dc4856e0958d6e 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -27,45 +27,45 @@ ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre
 livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
 tipo unix, e non è detto che sia applicabile a un filesystem
 qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
 livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
 tipo unix, e non è detto che sia applicabile a un filesystem
 qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,

-  per il quale vengono assegnati in maniera fissa con un opzione in fase di
-  montaggio}.  Esistono inoltre estensioni che permettono di implementare le
-ACL (\textit{Access Control List}) che sono un meccanismo di controllo di
-accesso molto più sofisticato.
+  per il quale i permessi vengono assegnati in maniera fissa con un opzione in
+  fase di montaggio}.  Esistono inoltre estensioni che permettono di
+implementare le ACL (\textit{Access Control List}) che sono un meccanismo di
+controllo di accesso molto più sofisticato.

 
 Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
 \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
 
 Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
 \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli

-identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}), e accessibili
-da programma tramite i campi \var{st\_uid} e \var{st\_gid} della struttura
-\var{stat} (si veda \secref{sec:filedir_stat}). Ad ogni file viene inoltre
-associato un insieme di permessi che sono divisi in tre classi, e cioè
-attribuiti rispettivamente all'utente proprietario del file, a un qualunque
-utente faccia parte del gruppo cui appartiene il file, e a tutti gli altri
-utenti.
-
-I permessi, così come vengono presi dai comandi e dalle routine di sistema
+identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}). Questi valori
+sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
+della struttura \var{stat} (si veda \secref{sec:filedir_stat}). Ad ogni file
+viene inoltre associato un insieme di permessi che sono divisi in tre classi,
+e cioè attribuiti rispettivamente all'utente proprietario del file, a un
+qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
+altri utenti.
+
+I permessi, così come vengono presi dai comandi e dalle routine di sistema,

 sono espressi da un numero di 12 bit; di questi i nove meno significativi sono
 usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
 sono espressi da un numero di 12 bit; di questi i nove meno significativi sono
 usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed

-esecuzione (indicati rispettivamente con le lettere \textsl{w}, \textit{r}
-\textsl{x} nei comandi di sistema) applicabili rispettivamente al
-proprietario, al gruppo, a tutti.  I restanti tre bit (\textsl{suid},
-\textsl{sgid}, e \textsl{sticky}) sono usati per indicare alcune
-caratteristiche più complesse su cui torneremo in seguito (vedi
-\secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}).
+esecuzione (indicati nei comandi di sistema con le lettere \textsl{w},
+\textit{r} \textsl{x}) ed applicabili rispettivamente al proprietario, al
+gruppo, a tutti.  I restanti tre bit (\textsl{suid}, \textsl{sgid}, e
+\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
+su cui torneremo in seguito (vedi \secref{sec:filedir_suid_sgid} e
+\secref{sec:filedir_sticky}).

 
 Anche i permessi sono tenuti per ciascun file (di qualunque tipo, quindi anche
 per le fifo, i socket e i file di dispositivo) nell'inode, in opportuni bit
 del campo \var{st\_mode} della struttura letta da \func{stat} (vedi
 \figref{fig:filedir_stat_struct}). 
 
 
 Anche i permessi sono tenuti per ciascun file (di qualunque tipo, quindi anche
 per le fifo, i socket e i file di dispositivo) nell'inode, in opportuni bit
 del campo \var{st\_mode} della struttura letta da \func{stat} (vedi
 \figref{fig:filedir_stat_struct}). 
 

-

 In genere ci si riferisce a questi permessi usando le lettere \textsl{u} (per
 \textit{user}), \textsl{g} (per \textit{group}) e \textsl{o} (per
 \textit{other}), inoltre se si vuole indicare tutti questi gruppi insieme si
 usa la lettera \textsl{a} (per \textit{all}). Si tenga ben presente questa
 In genere ci si riferisce a questi permessi usando le lettere \textsl{u} (per
 \textit{user}), \textsl{g} (per \textit{group}) e \textsl{o} (per
 \textit{other}), inoltre se si vuole indicare tutti questi gruppi insieme si
 usa la lettera \textsl{a} (per \textit{all}). Si tenga ben presente questa

-distinzione, dato che in certi casi, mutuando la terminologia in uso nel VMS,
+distinzione dato che in certi casi, mutuando la terminologia in uso nel VMS,

 si parla dei permessi base come di permessi di owner, group ed all, le cui
 iniziali possono da luogo a confusione. Le costanti che permettono di accedere
 si parla dei permessi base come di permessi di owner, group ed all, le cui
 iniziali possono da luogo a confusione. Le costanti che permettono di accedere

-al valore numerico di questi bit sono riportate in \ntab.
+al valore numerico di questi bit nel campo \var{st\_mode} sono riportate in
+\ntab.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -112,23 +112,31 @@ directory (se si hanno i permessi opportuni per il medesimo) ma non si potr
 vederlo con \cmd{ls} (per crearlo occorrerà anche il permesso di scrittura per
 la directory).
 
 vederlo con \cmd{ls} (per crearlo occorrerà anche il permesso di scrittura per
 la directory).
 

-Il permesso di lettura per un file consente di aprirlo con le opzioni di sola
-lettura (\macro{O\_RDONLY}) o di lettura-scrittura (\macro{O\_RDWR}) e
-leggerne il contenuto. Il permesso di scrittura consente di aprire un file in
-sola scrittura (\macro{O\_WRONLY}) o lettura-scrittura (\macro{O\_RDWR}) e
-modificarne il contenuto, lo stesso permesso è necessario per poter troncare
-il file con l'opzione \macro{O\_TRUNC}.
+Avere il permesso di lettura per un file consente di aprirlo con le opzioni di
+sola lettura (\macro{O\_RDONLY}) o di lettura-scrittura (\macro{O\_RDWR}) e
+leggerne il contenuto. Avere il permesso di scrittura consente di aprire un
+file in sola scrittura (\macro{O\_WRONLY}) o lettura-scrittura
+(\macro{O\_RDWR}) e modificarne il contenuto, lo stesso permesso è necessario
+per poter troncare il file con l'opzione \macro{O\_TRUNC}.

 
 Non si può creare un file fintanto che non si disponga del permesso di
 esecuzione e di quello di scrittura per la directory di destinazione; gli
 stessi permessi occorrono per cancellare un file da una directory (si ricordi
 che questo non implica necessariamente la rimozione fisica del file), non è
 necessario nessun tipo di permesso per il file stesso (infatti esso non viene
 
 Non si può creare un file fintanto che non si disponga del permesso di
 esecuzione e di quello di scrittura per la directory di destinazione; gli
 stessi permessi occorrono per cancellare un file da una directory (si ricordi
 che questo non implica necessariamente la rimozione fisica del file), non è
 necessario nessun tipo di permesso per il file stesso (infatti esso non viene

-toccato, viene solo modificato il contenute della directory).
+toccato, viene solo modificato il contenuto della directory, rimuovendo la
+voce che ad esso fa rifermento).

 
 Per poter eseguire un file (che sia un programma compilato od uno script di
 shell), occorre il permesso di esecuzione per il medesimo, inoltre solo i file
 
 Per poter eseguire un file (che sia un programma compilato od uno script di
 shell), occorre il permesso di esecuzione per il medesimo, inoltre solo i file

-regolari possono essere eseguiti.
+regolari possono essere eseguiti. 
+
+I permessi per un link simbolico sono ignorati, contano quelli del file a cui
+fa riferimento; per questo in genere \cmd{ls} per un link simbolico riporta
+tutti i permessi come concessi; anche utente e gruppo a cui appartiene vengono
+ignorati quando il link viene risolto, vengono controllati sono quando viene
+richiesta la rimozione del link e quest'ultimo è in una directory con lo
+\textsl{sticky bit} settato (vedi \secref{sec:filedir_sticky}).

 
 La procedura con cui il kernel stabilisce se un processo possiede un certo
 permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
 
 La procedura con cui il kernel stabilisce se un processo possiede un certo
 permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra


@@ -169,7 +177,7 @@ di accesso sono i seguenti:
   del file) allora:
   \begin{itemize}
   \item se il relativo\footnote{per relativo si intende il bit di user-read se
   del file) allora:
   \begin{itemize}
   \item se il relativo\footnote{per relativo si intende il bit di user-read se

-      il processo, vuole accedere in scrittura, quello di user-write per
+      il processo vuole accedere in scrittura, quello di user-write per

       l'accesso in scrittura, etc.} bit dei permessi d'accesso dell'utente è
     settato, l'accesso è consentito
   \item altrimenti l'accesso è negato
       l'accesso in scrittura, etc.} bit dei permessi d'accesso dell'utente è
     settato, l'accesso è consentito
   \item altrimenti l'accesso è negato


@@ -179,7 +187,8 @@ di accesso sono i seguenti:
   allora:
   \begin{itemize}
   \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
   allora:
   \begin{itemize}
   \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è

-    consentito, altrimenti l'accesso è negato
+    consentito, 
+  \item altrimenti l'accesso è negato

   \end{itemize}
 \item se il bit dei permessi d'accesso per tutti gli altri è settato,
   l'accesso è consentito,  altrimenti l'accesso è negato.
   \end{itemize}
 \item se il bit dei permessi d'accesso per tutti gli altri è settato,
   l'accesso è consentito,  altrimenti l'accesso è negato.


@@ -239,42 +248,42 @@ questi bit. Infine questi bit possono essere controllati all'interno di
 \tabref{tab:filedir_file_mode_flags}.
 
 Gli stessi bit vengono ad assumere in significato completamente diverso per le
 \tabref{tab:filedir_file_mode_flags}.
 
 Gli stessi bit vengono ad assumere in significato completamente diverso per le

-directory, normalmente infatti linux usa la convezione di SVR4 per indicare
+directory, normalmente infatti Linux usa la convezione di SVR4 per indicare

 con questi bit l'uso della semantica BSD nella creazione di nuovi file (si
 con questi bit l'uso della semantica BSD nella creazione di nuovi file (si

-veda \secref{sec:filedir_ownership}).
-
-Infine il caso in cui il file abbia il bit \textsl{sgid} settato ma non il
-corrispondente bit per l'esecuzione viene utilizzato per attivare per quel
-file il \textit{mandatory locking} (argomento affrontato nei dettagli in
-\secref{sec:xxx_mandatory_lock}).
+veda \secref{sec:filedir_ownership} per una spiegazione al proposito).

 
 

+Infine Linux utilizza il bit \textsl{sgid} per una ulteriore estensione
+mutuata da SVR4; il caso in cui il file abbia il bit \textsl{sgid} settato ma
+non il corrispondente bit per l'esecuzione viene infatti utilizzato per
+attivare per quel file il \textit{mandatory locking} (argomento che
+affronteremo nei dettagli in \secref{sec:xxx_mandatory_lock}).

 
 \subsection{Il bit \textsl{sticky}}
 \label{sec:filedir_sticky}
 
 L'ultimo dei bit rimanenti, identificato dalla costante \macro{S\_ISVTX} è in
 
 \subsection{Il bit \textsl{sticky}}
 \label{sec:filedir_sticky}
 
 L'ultimo dei bit rimanenti, identificato dalla costante \macro{S\_ISVTX} è in

-parte un rimasuglio delle origini dei sistemi Unix. A quell'epoca infatti la
+parte un rimasuglio delle origini dei sistemi unix. A quell'epoca infatti la

 memoria virtuale e l'accesso ai files erano molto meno sofisticati e per
 ottenere la massima velocità possibile per i programmi usati più comunemente
 si poteva settare questo bit.  
 
 memoria virtuale e l'accesso ai files erano molto meno sofisticati e per
 ottenere la massima velocità possibile per i programmi usati più comunemente
 si poteva settare questo bit.  
 

-L'effetto di questo bit è che il segmento di testo del programma (si veda
+L'effetto di questo bit era che il segmento di testo del programma (si veda

 \secref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la
 prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della
 mecchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file
 continuo indicizzato direttamente in questo modo si poteva risparmiare in
 tempo di caricamento rispetto alla ricerca del file su disco.
 
 \secref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la
 prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della
 mecchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file
 continuo indicizzato direttamente in questo modo si poteva risparmiare in
 tempo di caricamento rispetto alla ricerca del file su disco.
 

-Ovviamente per evitare che gli utenti possano intasare la swap solo
-l'amministratore è in grado di settare questo bit, che venne poi chiamato
+Ovviamente per evitare che gli utenti potessero intasare la swap solo
+l'amministratore era in grado di settare questo bit, che venne poi chiamato

 anche \textit{saved text bit}, da cui deriva il nome della costante. Le
 attuali implementazioni di memoria virtuale e filesystem rendono
 sostanzialmente inutile questo procedimento.
 
 Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
 invece assunto un uso corrente per le directory\footnote{lo \textsl{sticky
 anche \textit{saved text bit}, da cui deriva il nome della costante. Le
 attuali implementazioni di memoria virtuale e filesystem rendono
 sostanzialmente inutile questo procedimento.
 
 Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
 invece assunto un uso corrente per le directory\footnote{lo \textsl{sticky

-    bit} è una estensione non definita nello standard POSIX, linux la
-  supporta, così come BSD e SRV4}, se il bit è settato infatti un file può
+    bit} è una estensione non definita nello standard POSIX, Linux però la
+  supporta, così come BSD e SVR4}, se il bit è settato infatti un file può

 essere rimosso dalla directory soltanto se l'utente ha il permesso di
 scrittura ed inoltre è vera una delle seguenti condizioni:
 \begin{itemize}
 essere rimosso dalla directory soltanto se l'utente ha il permesso di
 scrittura ed inoltre è vera una delle seguenti condizioni:
 \begin{itemize}


@@ -294,21 +303,134 @@ cancellarlo o rinominarlo.
 \subsection{La titolarità di nuovi file e directory}
 \label{sec:filedir_ownership}
 
 \subsection{La titolarità di nuovi file e directory}
 \label{sec:filedir_ownership}
 

-Come spiegato in \secref{} per creare un nuovo file in una directory occorre
-avere il permesso di scrittura, ma 
+Vedremo in \secref{sec:fileunix_base_func} quali sono le funzioni per creare
+nuovi file, ma se è possibile specificare in sede di creazione quali permessi
+applicare ad un nuovo file, non si può indicare a quale utente e gruppo deve
+appartenere. Lo stesso problema di presenta per la creazione di nuove
+directory (descritto in \secref{sec:filedir_dir_creat_rem}).
+
+Lo standard POSIX prescrive che l'uid del nuovo file corrisponda
+all'\textit{effective user id} del processo che lo crea; per il gid invece
+prevede due diverse possibilità:
+\begin{itemize}
+\item il gid del file corrisponde all'\textit{effective group id} del processo
+\item il gid del file corrisponde al gid della directory in cui esso è creato
+\end{itemize}
+in genere BSD usa sempre la seconda possibilità, che viene per questo anche
+chiamata semantica BSD. Linux invece segue quella che viene chiamata semantica
+SVR4; di norma cioè il nuovo file viene creato con il gid del processo, se
+però la directory in cui viene creato il file ha il bit sgid settato allora
+viene usato il gid di quest'ultima.
+
+Usare la semantica BSD ha il vantaggio che il gid viene sempre automaticamente
+propagato, restando coerente a quello della directory di partenza, in tutte le
+sottodirectory, la semantica SVR4 offre una maggiore possibilità di scelta, ma
+per ottenere lo stesso risultato necessita che per le nuove directory venga
+anche propagato anche il bit sgid, questo è comunque il comportamento di
+default di \func{mkdir}, ed é in questo modo ad esempio che Debian assicura
+che le sottodirectory create nelle home di un utente restino sempre con il gid
+del gruppo primario dello stesso.

 
 
 \subsection{La funzione \texttt{access}}
 \label{sec:filedir_access}
 
 
 
 \subsection{La funzione \texttt{access}}
 \label{sec:filedir_access}
 

+Come detto in \secref{sec:filedir_access_control} il controllo di accesso ad
+un file viene fatto usando \textit{effective user id} e \textit{effective
+  group id} del processo, ma ci sono casi in cui si può voler effettuare il
+controllo usando il \textit{real user id} e il \textit{real group id} (cioè
+l'uid dell'utente che ha lanciato il programma, che, come accennato in
+\secref{sec:filedir_suid_sgid} e spiegato in \secref{sec:prochand_perms} non è
+detto sia uguale all'\textit{effective user id}). Per far questo si può usare
+la funzione \func{access}, il cui prototipo è:
+
+\begin{prototype}{unistd.h}
+{int access(const char *pathname, int mode)}
+
+  La funzione verifica i permessi di accesso, indicati da \var{mode}, per il
+  file indicato da \var{pathname}. 
+  
+  La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
+  quest'utlimo caso la variabile \texttt{errno} viene settata secondo i codici
+  di errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL},
+  \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP},
+  \macro{EIO}.
+\end{prototype}
+
+I valori possibili per il parametro \var{mode} sono esprimibili come
+combinazione delle costanti numeriche riportate in \ntab\ (attraverso un OR
+binario). I primi tre valori implicano anche la verifica dell'esistenza del
+file, se si vuole verificare solo quest'ultimaa si può usare \macro{F\_OK}, o
+anche direttamente \func{stat}. In caso \var{pathname} si riferisca ad un link
+simbolico il controllo è fatto sul file a cui esso fa riferimento.
+
+La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
+fatto che una directory abbia permesso di scrittura non significa che ci si
+possa scrivere come in un file, e il fatto che un file abbia permesso di
+esecuzione non comporta che contenga un programma eseguibile. La funzione
+ritorna zero solo se tutte i permessi controllati sono disponibili, in caso
+contrario (o di errore) ritorna -1.
+
+\begin{table}[htb]
+  \centering
+  \begin{tabular}{|c|l|}
+    \hline
+    \var{mode} & Significato \\
+    \hline
+    \hline
+    \macro{R\_OK} & verifica il permesso di lettura \\
+    \macro{W\_OK} & verifica il permesso di scritture \\
+    \macro{X\_OK} & verifica il permesso di esecuzione \\
+    \macro{F\_OK} & verifica l'esistenza del file \\
+    \hline
+  \end{tabular}
+  \caption{Valori possibile per il parametro \var{mode} della funzione 
+    \func{access}}
+  \label{tab:filedir_access_mode_val}
+\end{table}
+
+Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
+eseguendo un programma coi privilegi di un altro utente (attraverso l'uso del
+suid bit) che vuole controllare se l'utente originale ha i permessi per
+accedere ad un certo file.
+

 
 \subsection{La funzione \texttt{umask}}
 \label{sec:filedir_umask}
 
 
 \subsection{La funzione \texttt{umask}}
 \label{sec:filedir_umask}
 

+Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
+nuovi file sono controllati anche da una maschera di bit settata con la
+funzione \func{umask}. Questa viene utilizzata per impedire che alcuni
+permessi possano essere assegnati ai nuovi file, tutti i bit indicati nella
+maschera vengono infatti esclusi quando un nuovo file viene creato.
+

 
 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
 \label{sec:filedir_chmod}
 
 
 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
 \label{sec:filedir_chmod}
 

+Per cambiare i permessi di un file il sistema mette ad disposizione due
+funzioni, che operano rispettivamente su un filename e un file descriptor, i
+prototipi sono:
+
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/stat.h} 
+  
+  \funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del
+  file indicato da \var{path} al valore indicato da \var{mode}
+  
+  \funcdecl{chmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa il
+  file descriptor \var{fd} per indicare il file.
+
+
+  Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
+  caso di errore \texttt{errno} viene settato ai valori:
+  \begin{errlist}
+  \item \texttt{EPERM} L'uid non corrisponde a quello del file o non è zero.
+  \end{errlist}
+\end{functions}
+
+

 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
 \label{sec:filedir_chown}
 
 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
 \label{sec:filedir_chown}
 


@@ -364,9 +486,6 @@ i seguenti:
   \begin{errlist}
   \item \texttt{EACCESS} non c'è il permesso di accedere al file.
   \item \texttt{ENOTDIR} una componente del pathname non è una directory.
   \begin{errlist}
   \item \texttt{EACCESS} non c'è il permesso di accedere al file.
   \item \texttt{ENOTDIR} una componente del pathname non è una directory.

-  \item \texttt{EMLOOP} ci sono troppi link simbolici nel pathname.
-  \item \texttt{EFAULT} i puntatori usati sono fuori dallo spazio di indirizzi
-    del processo.

   \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
     completare l'operazione. 
   \item \texttt{ENAMETOOLONG} il filename è troppo lungo.
   \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
     completare l'operazione. 
   \item \texttt{ENAMETOOLONG} il filename è troppo lungo.


@@ -1014,8 +1133,6 @@ questa funzione 
     su un filesystem montato readonly.
   \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
     link è piena e non c'è ulteriore spazio disponibile.
     su un filesystem montato readonly.
   \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
     link è piena e non c'è ulteriore spazio disponibile.

-  \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
-    \texttt{oldname} o di \texttt{newname}.

   \end{errlist}
 \end{prototype}
 
   \end{errlist}
 \end{prototype}
 


@@ -1079,9 +1196,13 @@ interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
   (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
   visti dal sistema operativo.}. 
 
   (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 
+Questo può causare problemi per tutti quei programmi che effettuano lo scan di
+una directory senza tener conto dei link simbolici, ad esempio se lanciassimo
+un comando del tipo \cmd{grep -r linux *}, il loop nella directory porterebbe
+il comando ad esaminare \file{/boot}, \file/{boot/boot}, \file/{boot/boot/boot}
+e così via, fino a generare un errore (che poi è \macro{ELOOP}) quando viene
+superato il numero massimo di link simbolici consentiti (uno dei limiti del
+sistema, posto proprio per poter uscire da questo tipo di situazione).

 
 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
 
 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


@@ -1110,7 +1231,7 @@ programma deve includere il file \texttt{sys/types.h}.
 \begin{prototype}{sys/stat.h}
 {int mkdir (const char * dirname, mode\_t mode)}
   Questa funzione crea una nuova directory vuota con il nome indicato da
 \begin{prototype}{sys/stat.h}
 {int mkdir (const char * dirname, mode\_t mode)}
   Questa funzione crea una nuova directory vuota con il nome indicato da

-  \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
+  \var{dirname}, assegnandole i permessi indicati da \var{mode}. Il nome

   può essere indicato con il pathname assoluto o relativo.
   
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   può essere indicato con il pathname assoluto o relativo.
   
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso

diff --git a/fileintro.tex b/fileintro.tex
index fa05ce3efcb08bdfb150dcaf717e628ff794d31b..143c7e1dc205070b02ab6d6be98bc3b428c9aa2a 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -187,7 +187,8 @@ accedere al loro contenuto.
 
 La prima è l'interfaccia standard di unix, quella che il manuale delle glibc
 chiama interfaccia dei descrittori di file (o \textit{file descriptor}).  È
 
 La prima è l'interfaccia standard di unix, quella che il manuale delle glibc
 chiama interfaccia dei descrittori di file (o \textit{file descriptor}).  È

-un'interfaccia specifica di unix e provvede un accesso non bufferizzato.
+un'interfaccia specifica di unix e provvede un accesso non bufferizzato, la
+tratteremo in dettaglio in \capref{cha:file_unix_interface}.

 
 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
 
 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando


@@ -199,9 +200,11 @@ nell'header \texttt{unistd.h}.
 
 La seconda interfaccia è quella che il manuale della glibc chiama degli
 \textit{stream}, essa provvede funzioni più evolute e un accesso bufferizzato
 
 La seconda interfaccia è quella che il manuale della glibc chiama degli
 \textit{stream}, essa provvede funzioni più evolute e un accesso bufferizzato

-(controllato dalla implementazione fatta dalle librerie del C).  Questa è
-l'interfaccia standard specificata dall'ANSI C e perciò si trova anche su
-tutti i sistemi non Unix. Gli stream sono oggetti complessi e sono
+(controllato dalla implementazione fatta dalle librerie del C), la tratteremo
+in dettaglio in \capref{cha:files_std_interface}.
+
+Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
+anche su tutti i sistemi non unix. Gli stream sono oggetti complessi e sono

 rappresentati da puntatori ad un opportuna struttura definita dalle librerie
 del C, si accede ad essi sempre in maniera indiretta utilizzando il tipo
 \texttt{FILE *}.  L'interfaccia è definita nell'header \texttt{stdio.h}.
 rappresentati da puntatori ad un opportuna struttura definita dalle librerie
 del C, si accede ad essi sempre in maniera indiretta utilizzando il tipo
 \texttt{FILE *}.  L'interfaccia è definita nell'header \texttt{stdio.h}.


@@ -240,10 +243,10 @@ pertanto di portabilit
 \label{sec:fileint_unix_spec}
 
 Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
 \label{sec:fileint_unix_spec}
 
 Essendo un sistema multitasking e multiutente esistono alcune caratteristiche

-specifiche di Unix che devono essere tenute in conto nell'accesso ai file. È
-infatti normale che più processi o programmi possano accedere
-contemporaneamente allo stesso file e devono poter eseguire le loro operazioni
-indipendentemente da quello che fanno gli altri processi.
+specifiche di un sistema unix-like che devono essere tenute in conto
+nell'accesso ai file. È infatti normale che più processi o programmi possano
+accedere contemporaneamente allo stesso file e devono poter eseguire le loro
+operazioni indipendentemente da quello che fanno gli altri processi.

 
 Per questo motivo le strutture usate per all'accesso ai file sono relative al
 processo che effettua l'accesso.  All'apertura di ogni file infatti viene
 
 Per questo motivo le strutture usate per all'accesso ai file sono relative al
 processo che effettua l'accesso.  All'apertura di ogni file infatti viene


@@ -282,23 +285,22 @@ saranno disponibili per tutto il tempo in cui il processo 
 Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
 esaminando in dettaglio come tutto ciò viene realizzato.
 
 Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
 esaminando in dettaglio come tutto ciò viene realizzato.
 

-Si ricordi infine che in unix non esistono i tipi di file e che non c'è nessun
-supporto per le estensioni come parte del filesystem. Ciò non ostante molti
-programmi adottano delle convenzioni per i nomi dei file, ad esempio il codice
-C normalmente si mette in file con l'estensione .c, ma questa è, appunto, solo
-una convenzione.
-
+Si ricordi infine che in ambiente unix non esistono i tipi di file e che non
+c'è nessun supporto per le estensioni come parte del filesystem. Ciò non
+ostante molti programmi adottano delle convenzioni per i nomi dei file, ad
+esempio il codice C normalmente si mette in file con l'estensione .c, ma
+questa è, appunto, solo una convenzione.

 
 
 \section{L'architettura della gestione dei file}
 \label{sec:fileintr_architecture}
 
 Per capire fino in fondo le proprietà di files e directories in un sistema
 
 
 \section{L'architettura della gestione dei file}
 \label{sec:fileintr_architecture}
 
 Per capire fino in fondo le proprietà di files e directories in un sistema

-unix ed il funzionamento delle relative funzioni di manipolazione occorre una
-breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è basato
-un filesystem unix. In particolare occorre tenere presente dov'è che si situa
-la divisione fondamentale fra kernel space e user space che tracciavamo al
-\capref{cha:intro_unix}.
+unix-like ed il funzionamento delle relative funzioni di manipolazione occorre
+una breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è
+basato un filesystem di tipo unix. In particolare occorre tenere presente
+dov'è che si situa la divisione fondamentale fra kernel space e user space che
+tracciavamo al \capref{cha:intro_unix}.

 
 In questa sezione esamineremo come viene implementato l'accesso ai files in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
 
 In questa sezione esamineremo come viene implementato l'accesso ai files in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo


@@ -585,7 +587,7 @@ caratteristiche di un filesystem standard unix, 
 filenames lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
 4~Tb. 
 
 filenames lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
 4~Tb. 
 

-Oltre alle caratteristiche standard \testsl{ext2} fornisce alcune estensioni
+Oltre alle caratteristiche standard \textsl{ext2} fornisce alcune estensioni

 che non sono presenti sugli altri filesystem unix, le cui principali sono le
 seguenti:
 \begin{itemize}
 che non sono presenti sugli altri filesystem unix, le cui principali sono le
 seguenti:
 \begin{itemize}

diff --git a/fileunix.tex b/fileunix.tex
index a4fb47991a1450c23e02113f3c90aa177e7f2ac5..4d9daef3e2bb12057b9dba6e1a20ced630b09426 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -1,11 +1,9 @@
 \chapter{I files: l'interfaccia I/O di unix}
 \label{cha:file_unix_interface}
 
 \chapter{I files: l'interfaccia I/O di unix}
 \label{cha:file_unix_interface}
 

-Per poter accedere al contenuto dei file occorre anzitutto aprirlo. Questo
-crea un canale di comunicazione che permette di eseguire una serie di
-operazioni. Una volta terminate le operazioni, il file dovrà essere chiuso, e
-questo chiuderà il canale di comunicazione impedendo ogni ulteriore
-operazione.
+
+Esamineremo in questo capitolo la prima delle due interfacce di programmazione
+per i file, quella dei file descriptor, nativa di unix.

 
 
 
 
 
 


@@ -13,6 +11,12 @@ operazione.
 \label{sec:fileunix_fd}
 
 
 \label{sec:fileunix_fd}
 
 

+Per poter accedere al contenuto dei file occorre anzitutto aprirlo. Questo
+crea un canale di comunicazione che permette di eseguire una serie di
+operazioni. Una volta terminate le operazioni, il file dovrà essere chiuso, e
+questo chiuderà il canale di comunicazione impedendo ogni ulteriore
+operazione.
+

 \section{Le funzioni base}
 \label{sec:fileunix_base_func}
 
 \section{Le funzioni base}
 \label{sec:fileunix_base_func}
 

diff --git a/gapil.tex b/gapil.tex
index 13711b062b3da6f2d866a226df8a9dced9683377..8e81f4cccf04b70850e274be2fe0259bd791c20a 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -1,4 +1,4 @@
-%%
+%% 

 %% GaPiL : Guida alla Programmazione in Linux
 %%
 %% S. Piccardi Feb. 2001
 %% GaPiL : Guida alla Programmazione in Linux
 %%
 %% S. Piccardi Feb. 2001

diff --git a/intro.tex b/intro.tex
index f287e9c6b5e5503247913bca782c22d06c6b3250..4442d526fd6050c83b96009a0e245973212064db 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -326,9 +326,9 @@ che c'
 Per riportare il tipo di errore il sistema usa la variabile globale
 \var{errno}\footnote{L'uso di una variabile globale può comportare alcuni
   problemi (ad esempio nel caso dei thread) ma lo standard ISO C consente
 Per riportare il tipo di errore il sistema usa la variabile globale
 \var{errno}\footnote{L'uso di una variabile globale può comportare alcuni
   problemi (ad esempio nel caso dei thread) ma lo standard ISO C consente

-  anche di definire \var{errno} come un \textit{modifible lvalue}, quindi su
-  può anche usare 
-
+  anche di definire \var{errno} come un \textit{modifible lvalue}, quindi si
+  può anche usare una macro, e questo è infatti il modo usato da Linux per
+  renderla locale ai singoli thread

 }, definita nell'header \file{errno.h}, la variabile è in genere
 definita come \var{volatile} dato che può essere cambiata in modo asincrono da
 un segnale (per una descrizione dei segnali si veda \secref{cha:signal}), ma
 }, definita nell'header \file{errno.h}, la variabile è in genere
 definita come \var{volatile} dato che può essere cambiata in modo asincrono da
 un segnale (per una descrizione dei segnali si veda \secref{cha:signal}), ma

diff --git a/signal.tex b/signal.tex
index 37243adef49312150641efc1b95b2c3122fcb8e3..897d50611f87000d08fc80f7893616938c7a4a44 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -646,7 +646,7 @@ contenuto, che resta valido solo fino alla successiva chiamata di
 necessario copiarlo.
 
 La seconda funzione deriva da BSD ed è analoga alla funzione \func{perror}
 necessario copiarlo.
 
 La seconda funzione deriva da BSD ed è analoga alla funzione \func{perror}

-descritta in \secref{
+descritta in \secref{}

 
 
 \section{La gestione dei segnali}
 
 
 \section{La gestione dei segnali}

diff --git a/simpltcp.tex b/simpltcp.tex
index 3c10daae8d1d1265a94f6a5947ad1d8b94fc9659..e594d2d1b85b39ec56dd8de9a609d5e429bb30b6 100644 (file)
--- a/simpltcp.tex
+++ b/simpltcp.tex
@@ -388,7 +388,7 @@ casi seguenti:
 \end{enumerate}
 
 
 \end{enumerate}
 
 

-\subsection{La gestione dei procesi figli}
+\subsection{La gestione dei processi figli}

 \label{sec:TCPsimpl_child_hand}
 
 Tutto questo riguarda la connessione, c'è però un'altro effetto del
 \label{sec:TCPsimpl_child_hand}
 
 Tutto questo riguarda la connessione, c'è però un'altro effetto del