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
\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 è
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}
processi in user space possono accedere alle operazioni attraverso detti
metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
(su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle
-operazioni previste dal kernel è riportato in \ntab.
+operazioni previste dal kernel è riportato in
+\tabref{tab:file_file_operations}.
\begin{table}[htb]
\centering
Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
partizione può contenere un filesystem. La strutturazione tipica
-dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
-alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
-in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
-di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
-comune di tutti i filesystem per Unix, indipendentemente da come poi viene
-strutturata nei dettagli questa informazione, prevedere una divisione fra la
-lista degli inodes e lo spazio a disposizione per i dati e le directory.
+dell'informazione su un disco è riportata in \figref{fig:file_disk_filesys};
+in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che
+prevede una separazione dei dati in \textit{blocks group} che replicano il
+superblock (ma sulle caratteristiche di \acr{ext2} torneremo in
+\secref{sec:file_ext2}). È comunque caratteristica comune di tutti i
+filesystem per Unix, indipendentemente da come poi viene strutturata nei
+dettagli questa informazione, prevedere una divisione fra la lista degli
+inodes e lo spazio a disposizione per i dati e le directory.
\begin{figure}[htb]
\centering
dell'informazione all'interno del singolo filesystem (tralasciando i dettagli
relativi al funzionamento del filesystem stesso come la strutturazione in
gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo
-esemplificare la situazione con uno schema come quello esposto in \nfig.
+esemplificare la situazione con uno schema come quello esposto in
+\figref{fig:file_filesys_detail}.
\begin{figure}[htb]
\centering
\label{fig:file_filesys_detail}
\end{figure}
-Da \curfig\ si evidenziano alcune delle caratteristiche di base di un
-filesystem, sulle quali è bene porre attenzione visto che sono fondamentali
-per capire il funzionamento delle funzioni che manipolano i file e le
-directory che tratteremo nel prossimo capitolo; in particolare è opportuno
-ricordare sempre che:
+Da \figref{fig:file_filesys_detail} si evidenziano alcune delle
+caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
+visto che sono fondamentali per capire il funzionamento delle funzioni che
+manipolano i file e le directory che tratteremo nel prossimo capitolo; in
+particolare è opportuno ricordare sempre che:
\begin{enumerate}
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
- numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
- solo quando questo contatore si annulla i dati del file vengono
- effettivamente rimossi dal disco. Per questo la funzione per cancellare un
- file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
- file, ma si limita ad eliminare la relativa voce da una directory e
- decrementare il numero di riferimenti nell'\textit{inode}.
+
+\item Come mostrato in \figref{fig:file_filesys_detail} si possono avere più
+ voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
+ contatore che contiene il numero di riferimenti (\textit{link count}) che
+ sono stati fatti ad esso; solo quando questo contatore si annulla i dati del
+ file vengono effettivamente rimossi dal disco. Per questo la funzione per
+ cancellare un file si chiama \func{unlink}, ed in realtà non cancella
+ affatto i dati del file, ma si limita ad eliminare la relativa voce da una
+ directory e decrementare il numero di riferimenti nell'\textit{inode}.
\item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
nello stesso filesystem e non ci può essere una directory che contiene
Infine è bene avere presente che, essendo file pure loro, esiste un numero di
riferimenti anche per le directory; per cui, se a partire dalla situazione
-mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
-\file{gapil}, avremo una situazione come quella in \nfig, dove per chiarezza
-abbiamo aggiunto dei numeri di inode.
+mostrata in \figref{fig:file_filesys_detail} creiamo una nuova directory
+\file{img} nella directory \file{gapil}, avremo una situazione come quella in
+\figref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri di
+inode.
\begin{figure}[htb]
\centering
Le directory sono implementate come una linked list con voci di dimensione
variabile. Ciascuna voce della lista contiene il numero di inode, la sua
-lunghezza, il nome del file e la sua lunghezza, secondo lo schema in \curfig;
-in questo modo è possibile implementare nomi per i file anche molto lunghi
-(fino a 1024 caratteri) senza sprecare spazio disco.
+lunghezza, il nome del file e la sua lunghezza, secondo lo schema in
+\figref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi per
+i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco.
projects / gapil.git / blobdiff