Esempio di come non fare una sleep. Da un vecchio suggerimento fatto

[gapil.git] / filedir.tex

diff --git a/filedir.tex b/filedir.tex
index bfcd9cadb457e0446fb9f89f0a7bc4fd522ea120..7720071700509a6dbbfd5891866c6e83e194e2c8 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -213,7 +213,7 @@ tab.~\ref{tab:file_inode_operations} le più rilevanti.
     \hline
     \hline
     \textsl{\code{create}} & Chiamata per creare un nuovo file (vedi
     \hline
     \hline
     \textsl{\code{create}} & Chiamata per creare un nuovo file (vedi

-                             sez.~\ref{sec:file_open}).\\ 
+                             sez.~\ref{sec:file_open_close}).\\ 

     \textsl{\code{link}}   & Crea un \textit{hard link} (vedi
                              sez.~\ref{sec:link_symlink_rename}).\\
     \textsl{\code{unlink}} & Cancella un \textit{hard link} (vedi
     \textsl{\code{link}}   & Crea un \textit{hard link} (vedi
                              sez.~\ref{sec:link_symlink_rename}).\\
     \textsl{\code{unlink}} & Cancella un \textit{hard link} (vedi


@@ -260,13 +260,13 @@ tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
   detta funzione.} Questo avviene perché su Linux l'apertura di un file
 richiede comunque un'altra operazione che mette in gioco l'omonimo oggetto del
 VFS: l'allocazione di una struttura di tipo \kstruct{file} che viene associata
   detta funzione.} Questo avviene perché su Linux l'apertura di un file
 richiede comunque un'altra operazione che mette in gioco l'omonimo oggetto del
 VFS: l'allocazione di una struttura di tipo \kstruct{file} che viene associata

-ad ogni file aperto nel sistema.
-
-I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
-come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
-operazioni eseguite dai processi con l'interfaccia dei file descriptor; ogni
-processo infatti mantiene il riferimento ad una struttura \kstruct{file} per
-ogni file che ha aperto, ed è tramite essa che esegue le operazioni di I/O.
+ad ogni file aperto nel sistema.  I motivi per cui viene usata una struttura a
+parte sono diversi, anzitutto, come illustrato in sez.~\ref{sec:file_fd},
+questa è necessaria per le operazioni eseguite dai processi con l'interfaccia
+dei file descriptor. Ogni processo infatti mantiene il riferimento ad una
+struttura \kstruct{file} per ogni file che ha aperto, ed è tramite essa che
+esegue le operazioni di I/O. Inoltre il kernel mantiene un elenco di tutti i
+file aperti nella \itindex{file~table} \textit{file table}.

 
 Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad
 oggetti posti all'interno di un filesystem e vi si applicano quindi le
 
 Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad
 oggetti posti all'interno di un filesystem e vi si applicano quindi le


@@ -304,7 +304,8 @@ tab.~\ref{tab:file_file_operations} le più significative.
     \textbf{Funzione} & \textbf{Operazione} \\
     \hline
     \hline
     \textbf{Funzione} & \textbf{Operazione} \\
     \hline
     \hline

-    \textsl{\code{open}}   & Apre il file (vedi sez.~\ref{sec:file_open}).\\
+    \textsl{\code{open}}   & Apre il file (vedi
+                             sez.~\ref{sec:file_open_close}).\\ 

     \textsl{\code{read}}   & Legge dal file (vedi sez.~\ref{sec:file_read}).\\
     \textsl{\code{write}}  & Scrive sul file (vedi 
                              sez.~\ref{sec:file_write}).\\
     \textsl{\code{read}}   & Legge dal file (vedi sez.~\ref{sec:file_read}).\\
     \textsl{\code{write}}  & Scrive sul file (vedi 
                              sez.~\ref{sec:file_write}).\\


@@ -1031,7 +1032,7 @@ nell'elenco seguente:
 \item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
   ogni modifica al contenuto del filesystem venga immediatamente registrata su
   disco. Lo stesso comportamento può essere ottenuto con il flag
 \item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
   ogni modifica al contenuto del filesystem venga immediatamente registrata su
   disco. Lo stesso comportamento può essere ottenuto con il flag

-  \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open}).
+  \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open_close}).

 
   Questa opzione consente di ridurre al minimo il rischio di perdita dei dati
   in caso di crollo improvviso del sistema, al costo di una pesante perdita di
 
   Questa opzione consente di ridurre al minimo il rischio di perdita dei dati
   in caso di crollo improvviso del sistema, al costo di una pesante perdita di


@@ -1546,8 +1547,8 @@ Si noti che non si è specificato il comportamento delle funzioni che operano
 con i file descriptor (che tratteremo nel prossimo capitolo), in quanto la
 risoluzione del collegamento simbolico viene in genere effettuata dalla
 funzione che restituisce il file descriptor (normalmente la \func{open}, vedi
 con i file descriptor (che tratteremo nel prossimo capitolo), in quanto la
 risoluzione del collegamento simbolico viene in genere effettuata dalla
 funzione che restituisce il file descriptor (normalmente la \func{open}, vedi

-sez.~\ref{sec:file_open}) e tutte le operazioni seguenti fanno riferimento
-solo a quest'ultimo.
+sez.~\ref{sec:file_open_close}) e tutte le operazioni seguenti fanno
+riferimento solo a quest'ultimo.

 
 Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
 \func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
 
 Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
 \func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per


@@ -1722,7 +1723,7 @@ sono stati cancellati: solo quando il numero di collegamenti mantenuto
 lo spazio occupato su disco viene liberato. Si tenga presente comunque che a
 questo si aggiunge sempre un'ulteriore condizione e cioè che non ci siano
 processi che abbiano il suddetto file aperto.\footnote{come vedremo in
 lo spazio occupato su disco viene liberato. Si tenga presente comunque che a
 questo si aggiunge sempre un'ulteriore condizione e cioè che non ci siano
 processi che abbiano il suddetto file aperto.\footnote{come vedremo in

-  cap.~\ref{cha:file_unix_interface} il kernel mantiene anche una tabella dei
+  sez.~\ref{sec:file_unix_interface} il kernel mantiene anche una tabella dei

   file aperti nei vari processi, che a sua volta contiene i riferimenti agli
   \itindex{inode} \textit{inode} ad essi relativi; prima di procedere alla
   cancellazione dello spazio occupato su disco dal contenuto di un file il
   file aperti nei vari processi, che a sua volta contiene i riferimenti agli
   \itindex{inode} \textit{inode} ad essi relativi; prima di procedere alla
   cancellazione dello spazio occupato su disco dal contenuto di un file il


@@ -1988,11 +1989,12 @@ 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
 leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo
 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
 leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo

-in sez.~\ref{sec:file_open} che è possibile aprire una directory come se fosse
-un file, anche se solo in sola lettura) in generale il formato con cui esse
-sono scritte può dipendere dal tipo di filesystem, tanto che, come riportato
-in tab.~\ref{tab:file_file_operations}, il \itindex{Virtual~File~System} VFS
-prevede una apposita funzione per la lettura delle directory.
+in sez.~\ref{sec:file_open_close} che è possibile aprire una directory come se
+fosse un file, anche se solo in sola lettura) in generale il formato con cui
+esse sono scritte può dipendere dal tipo di filesystem, tanto che, come
+riportato in tab.~\ref{tab:file_file_operations}, il
+\itindex{Virtual~File~System} VFS prevede una apposita funzione per la lettura
+delle directory.

 
 \itindbeg{directory~stream}
 
 
 \itindbeg{directory~stream}
 


@@ -2001,7 +2003,7 @@ Tutto questo si riflette nello standard POSIX\footnote{le funzioni erano
 che ha introdotto una apposita interfaccia per la lettura delle directory,
 basata sui cosiddetti \textit{directory stream}, chiamati così per l'analogia
 con i \textit{file stream} dell'interfaccia standard ANSI C che vedremo in
 che ha introdotto una apposita interfaccia per la lettura delle directory,
 basata sui cosiddetti \textit{directory stream}, chiamati così per l'analogia
 con i \textit{file stream} dell'interfaccia standard ANSI C che vedremo in

-cap.~\ref{cha:files_std_interface}. La prima funzione di questa interfaccia è
+sez.~\ref{sec:files_std_interface}. La prima funzione di questa interfaccia è

 \funcd{opendir}, il cui prototipo è:
 
 \begin{funcproto}{
 \funcd{opendir}, il cui prototipo è:
 
 \begin{funcproto}{


@@ -3012,8 +3014,8 @@ prototipo è:
 Come per \func{mktemp} anche in questo caso \param{template} non può essere
 una stringa costante. La funzione apre un file in lettura/scrittura con la
 funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda
 Come per \func{mktemp} anche in questo caso \param{template} non può essere
 una stringa costante. La funzione apre un file in lettura/scrittura con la
 funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda

-sez.~\ref{sec:file_open}), in questo modo al ritorno della funzione si ha la
-certezza di essere stati i creatori del file, i cui permessi (si veda
+sez.~\ref{sec:file_open_close}), in questo modo al ritorno della funzione si
+ha la certezza di essere stati i creatori del file, i cui permessi (si veda

 sez.~\ref{sec:file_perm_overview}) sono impostati al valore \code{0600}
 (lettura e scrittura solo per il proprietario).\footnote{questo è vero a
   partire dalla \acr{glibc} 2.0.7, le versioni precedenti della \acr{glibc} e
 sez.~\ref{sec:file_perm_overview}) sono impostati al valore \code{0600}
 (lettura e scrittura solo per il proprietario).\footnote{questo è vero a
   partire dalla \acr{glibc} 2.0.7, le versioni precedenti della \acr{glibc} e


@@ -3057,11 +3059,11 @@ In OpenBSD è stata introdotta un'altra funzione simile alle precedenti,
   più gli altri eventuali codici di errore di \func{mkdir}.}
 \end{funcproto}
 
   più gli altri eventuali codici di errore di \func{mkdir}.}
 \end{funcproto}
 

-La funzione genera una directory il cui nome è ottenuto sostituendo le
-\code{XXXXXX} finali di \param{template} con permessi \code{0700} (al solito
-si veda cap.~\ref{cha:file_unix_interface} per i dettagli). Dato che la
-creazione della directory è sempre esclusiva i precedenti problemi di
-\itindex{race~condition} \textit{race condition} non si pongono.
+La funzione crea una directory temporanea il cui nome è ottenuto sostituendo
+le \code{XXXXXX} finali di \param{template} con permessi \code{0700} (si veda
+sez.~\ref{sec:file_perm_overview} per i dettagli). Dato che la creazione della
+directory è sempre esclusiva i precedenti problemi di \itindex{race~condition}
+\textit{race condition} non si pongono.

 
 
 
 
 
 


@@ -3984,7 +3986,7 @@ crearlo o rinominarlo o cancellarlo invece occorrerà avere anche il permesso
 di scrittura per la directory.
 
 Avere il permesso di lettura per un file consente di aprirlo con le opzioni
 di scrittura per la directory.
 
 Avere il permesso di lettura per un file consente di aprirlo con le opzioni

-(si veda quanto riportato in tab.~\ref{tab:file_open_flags}) di sola lettura o
+(si veda quanto riportato in sez.~\ref{sec:file_open_close}) di sola lettura o

 di lettura/scrittura e leggerne il contenuto. Avere il permesso di scrittura
 consente di aprire un file in sola scrittura o lettura/scrittura e modificarne
 il contenuto, lo stesso permesso è necessario per poter troncare il file o per
 di lettura/scrittura e leggerne il contenuto. Avere il permesso di scrittura
 consente di aprire un file in sola scrittura o lettura/scrittura e modificarne
 il contenuto, lo stesso permesso è necessario per poter troncare il file o per


@@ -4465,11 +4467,11 @@ un'eventuale modifica comporterà la perdita di questo privilegio.
 Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
 permessi di un file, resta però il problema di quali sono i permessi assegnati
 quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come
 Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
 permessi di un file, resta però il problema di quali sono i permessi assegnati
 quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come

-vedremo in sez.~\ref{sec:file_open}, permettono di indicare esplicitamente i
-permessi di creazione di un file, ma questo non è possibile per le funzioni
-dell'interfaccia standard ANSI C che non prevede l'esistenza di utenti e
-gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
-permessi non vengono indicati esplicitamente. 
+vedremo in sez.~\ref{sec:file_open_close}, permettono di indicare
+esplicitamente i permessi di creazione di un file, ma questo non è possibile
+per le funzioni dell'interfaccia standard ANSI C che non prevede l'esistenza
+di utenti e gruppi, ed inoltre il problema si pone anche per l'interfaccia
+nativa quando i permessi non vengono indicati esplicitamente.

 
 \itindbeg{umask} 
 
 
 \itindbeg{umask} 
 


@@ -4517,7 +4519,7 @@ utenti non hanno motivi per modificarlo.
 \subsection{La gestione della titolarità dei file}
 \label{sec:file_ownership_management}
 
 \subsection{La gestione della titolarità dei file}
 \label{sec:file_ownership_management}
 

-Vedremo in sez.~\ref{sec:file_base_func} con quali funzioni si possono creare
+Vedremo in sez.~\ref{sec:file_open_close} con quali funzioni si possono creare

 nuovi file, in tale occasione vedremo che è possibile specificare in sede di
 creazione quali permessi applicare ad un file, però non si può indicare a
 quale utente e gruppo esso deve appartenere.  Lo stesso problema si presenta
 nuovi file, in tale occasione vedremo che è possibile specificare in sede di
 creazione quali permessi applicare ad un file, però non si può indicare a
 quale utente e gruppo esso deve appartenere.  Lo stesso problema si presenta


@@ -5275,7 +5277,7 @@ file) tutti quelli non presenti in \const{ACL\_MASK}.\footnote{questo diverso
 Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
 quello relativo alla creazione di nuovi file,\footnote{o oggetti sul
   filesystem, il comportamento discusso vale per le funzioni \func{open} e
 Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
 quello relativo alla creazione di nuovi file,\footnote{o oggetti sul
   filesystem, il comportamento discusso vale per le funzioni \func{open} e

-  \func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi
+  \func{creat} (vedi sez.~\ref{sec:file_open_close}), \func{mkdir} (vedi

   sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
   sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
 presenza di una \textit{Default ACL} sulla directory che andrà a contenerli.
   sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
   sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
 presenza di una \textit{Default ACL} sulla directory che andrà a contenerli.


@@ -6995,7 +6997,7 @@ sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
 \itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
 sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
 \const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
 \itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
 sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
 \const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi

-sez.~\ref{sec:file_open} e sez.~\ref{sec:file_fcntl}) senza restrizioni.
+sez.~\ref{sec:file_open_close} e sez.~\ref{sec:file_fcntl}) senza restrizioni.

 
 Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
 la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
 
 Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
 la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni