X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=359a1e26391e07f38de5b5186c64638d215997e8;hp=0a7bb94adc735105e3e06f5d715c6d464b8d1287;hb=d7a4a5240fead001955364f17b6f25a5d9578e4f;hpb=06a411c6242a35082817a74e9a86ec226d8bf0e3

diff --git a/fileintro.tex b/fileintro.tex
index 0a7bb94..359a1e2 100644
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -122,11 +122,26 @@ Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
-\textit{Virtual File System}\index{Virtual File System} è riportato in \ntab.
+\textit{Virtual File System}\index{Virtual File System} è riportato in
+\tabref{tab:file_file_types}.
 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con
-la classificazione sui tipi di file (che in questo caso sono sempre file di
-dati) in base al loro contenuto, o tipo di accesso.
+la classificazione dei file (che in questo caso sono sempre file di dati) in
+base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
+oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
+Alcuni di essi, come le \textit{fifo} (che tratteremo in
+\secref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
+\capref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
+delle funzionalità di comunicazione fornite dal kernel. Gli altri sono i
+\textsl{file di dispositivo} (o \textit{device file}) che costituiscono una
+interfaccia diretta per leggere e scrivere sui dispositivi fisici; essi
+vengono suddivisi in due grandi categorie, \textsl{a blocchi} e \textsl{a
+  caratteri} a seconda delle modalità in cui il dispositivo sottostante
+effettua le operazioni di I/O.\footnote{in sostanza i dispositivi a blocchi
+  (ad esempio i dischi) corrispondono a periferiche per le quali è richiesto
+  che l'I/O venga effettuato per blocchi di dati di dimensioni fissate (ad
+  esempio le dimensioni di un settore), mentre nei dispositivi a caratteri
+  l'I/O viene effettuato senza nessuna particolare struttura.}
 
 \begin{table}[htb]
   \footnotesize
@@ -136,7 +151,7 @@ dati) in base al loro contenuto, o tipo di accesso.
     \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
     \hline
     \hline
-      \textit{regular file} & \textsl{file normale} &
+      \textit{regular file} & \textsl{file regolare} &
       un file che contiene dei dati (l'accezione normale di file) \\
       \textit{directory} & \textsl{cartella o direttorio} &
       un file che contiene una lista di nomi associati a degli \textit{inodes}
@@ -159,16 +174,20 @@ dati) in base al loro contenuto, o tipo di accesso.
     \label{tab:file_file_types}
 \end{table}
 
-Infatti una delle differenze principali con altri sistemi operativi (come il
-VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono
-un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
-dal sistema file di diverso contenuto o formato (come nel caso di quella fra
-file di testo e binari che c'è in Windows) né c'è una strutturazione a record
-per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i
-  kernel della serie 2.4 è disponibile, attraverso dei device file appositi,
-  una forma di accesso diretto ai dischi (il \textit{raw access}) che però non
-  ha nulla a che fare con questo, trattandosi solo di operazioni fatte senza
-  passare attraverso un filesystem.}
+Una delle differenze principali con altri sistemi operativi (come il VMS o
+Windows) è che per Unix tutti i file di dati sono identici e contengono un
+flusso continuo di byte. Non esiste cioè differenza per come vengono visti dal
+sistema file di diverso contenuto o formato (come nel caso di quella fra file
+di testo e binari che c'è in Windows) né c'è una strutturazione a record per
+il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{questo vale
+  anche per i dispositivi a blocchi: la strutturazione dell'I/O in blocchi di
+  dimensione fissa avviene solo all'interno del kernel, ed è completamente
+  trasparente all'utente. Inoltre talvolta si parla di \textsl{accesso
+    diretto} riferendosi alla capacità, che non ha niente a che fare con tutto
+  ciò, di effettuare, attraverso degli appositi file di dispositivo,
+  operazioni di I/O direttamente sui dischi senza passare attraverso un
+  filesystem (il cosiddetto \textit{raw access}, introdotto coi kernel della
+  serie 2.4.x).}
 
 Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è
 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
@@ -179,12 +198,21 @@ del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux
 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 riga.
 
-Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
-dati e che non c'è nessun supporto del sistema per le estensioni come parte
-del filesystem. Ciò nonostante molti programmi adottano delle convenzioni per
-i nomi dei file, ad esempio il codice C normalmente si mette in file con
-l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
-universale, solo una convenzione.
+Si ricordi infine che un kernel Unix non fornisce nessun supporto per la
+tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
+estensioni come parte del filesystem.\footnote{non è così ad esempio nel
+  filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file,
+  che specificano fra l'altro il contenuto ed il programma da usare per
+  leggerlo. In realtà per alcuni filesystem, come l'XFS della SGI, esiste la
+  possibilità di associare delle risorse ai file, ma è una caratteristica
+  tutt'ora poco utilizzata, dato che non corrisponde al modello classico dei
+  file in un sistema Unix.} Ciò nonostante molti programmi adottano delle
+convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
+in file con l'estensione \file{.c}; un'altra tecnica molto usata è quella di
+utilizzare i primi 4 byte del file per memorizzare un \textit{magic number}
+che classifichi il contenuto; entrambe queste tecniche, per quanto usate ed
+accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è
+demandato alle applicazioni stesse.
 
 
 \subsection{Le due interfacce ai file}
@@ -515,7 +543,7 @@ lista degli inodes e lo spazio a disposizione per i dati e le directory.
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=12cm]{img/disk_struct}
+  \includegraphics[width=14cm]{img/disk_struct}
   \caption{Organizzazione dello spazio su un disco in partizioni e
   filesystem.}
   \label{fig:file_disk_filesys}
@@ -529,7 +557,7 @@ esemplificare la situazione con uno schema come quello esposto in \nfig.
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=12cm]{img/filesys_struct}
+  \includegraphics[width=14cm]{img/filesys_struct}
   \caption{Strutturazione dei dati all'interno di un filesystem.}
   \label{fig:file_filesys_detail}
 \end{figure}
@@ -547,10 +575,10 @@ ricordare sempre che:
   fisici che contengono i dati e così via; le informazioni che la funzione
   \func{stat} fornisce provengono dall'\textit{inode}; dentro una directory si
   troverà solo il nome del file e il numero dell'\textit{inode} ad esso
-  associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
-  (traduzione approssimata dell'inglese \textit{directory entry}, che non
-  useremo anche per evitare confusione con le \textit{dentry} del kernel di
-  cui si parlava in \secref{sec:file_vfs}).
+  associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
+  traduzione dell'inglese \textit{directory entry}, che non useremo anche per
+  evitare confusione con le \textit{dentry} del kernel di cui si parlava in
+  \secref{sec:file_vfs}).
 
 \item Come mostrato in \curfig\ si possono avere più voci che puntano allo
   stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
@@ -583,7 +611,7 @@ abbiamo aggiunto dei numeri di inode.
 
 \begin{figure}[htb]
   \centering 
-  \includegraphics[width=12cm]{img/dir_links}
+  \includegraphics[width=14cm]{img/dir_links}
   \caption{Organizzazione dei link per le directory.}
   \label{fig:file_dirs_link}
 \end{figure}
@@ -610,7 +638,7 @@ Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
 non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del
-  kernel quando agisce su gruppi di file. Possono essere settati su file e
+  kernel quando agisce su gruppi di file. Possono essere impostati su file e
   directory e in quest'ultimo caso i nuovi file creati nella directory
   ereditano i suoi attributi.
 \item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
@@ -618,7 +646,7 @@ non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
   con lo stesso identificatore di gruppo della directory che li contiene. La
   semantica SVr4 comporta che i file vengono creati con l'identificatore del
   gruppo primario del processo, eccetto il caso in cui la directory ha il bit
-  di \acr{sgid} settato (per una descrizione dettagliata del significato di
+  di \acr{sgid} impostato (per una descrizione dettagliata del significato di
   questi termini si veda \secref{sec:file_access_control}), nel qual caso file
   e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem