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
\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}
\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}
direttamente le system call del kernel (in realtà il kernel effettua al suo
interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
dispositivi); i \textit{file descriptor}\index{file descriptor} sono
-rappresentati da numeri interi (cioè semplici variabili di tipo \type{int}).
+rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{int}).
L'interfaccia è definita nell'header \file{unistd.h}.
La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
anche su tutti i sistemi non Unix. Gli \textit{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 \type{FILE *}. L'interfaccia è definita nell'header \type{stdio.h}.
+tipo \ctyp{FILE *}. L'interfaccia è definita nell'header \file{stdio.h}.
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
altri oggetti del VFS (fifo, socket, device, sui quali torneremo in dettaglio
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}[c]{|l|p{7cm}|}
+ \begin{tabular}[c]{|l|p{8cm}|}
\hline
\textbf{Funzione} & \textbf{Operazione} \\
\hline
\hline
- \textsl{\code{open}} & apre il file \\
- \textsl{\code{read}} & legge dal file \\
- \textsl{\code{write}} & scrive sul file \\
- \textsl{\code{llseek}} & sposta la posizione corrente sul file \\
+ \textsl{\code{open}} & apre il file (vedi \secref{sec:file_open}). \\
+ \textsl{\code{read}} & legge dal file (vedi \secref{sec:file_read}).\\
+ \textsl{\code{write}} & scrive sul file (vedi \secref{sec:file_write}).\\
+ \textsl{\code{llseek}} & sposta la posizione corrente sul file (vedi
+ \secref{sec:file_lseek}). \\
\textsl{\code{ioctl}} & accede alle operazioni di controllo
- (tramite la \func{ioctl})\\
- \textsl{\code{readdir}}& per leggere il contenuto di una directory \\
- \textsl{\code{poll}} & \\
- \textsl{\code{mmap}} & chiamata dalla system call \func{mmap}.
- mappa il file in memoria\\
+ (vedi \secref{sec:file_ioctl}).\\
+ \textsl{\code{readdir}}& legge il contenuto di una directory \\
+ \textsl{\code{poll}} & usata nell'I/O multiplexing (vedi
+ \secref{sec:file_multiplexing}). \\
+ \textsl{\code{mmap}} & mappa il file in memoria (vedi
+ \secref{sec:file_memory_map}). \\
\textsl{\code{release}}& chiamata quando l'ultima referenza a un file
- aperto è chiusa\\
- \textsl{\code{fsync}} & chiamata dalla system call \func{fsync} \\
- \textsl{\code{fasync}} & chiamate da \func{fcntl} quando è abilitato
- il modo asincrono per l'I/O su file. \\
+ aperto è chiusa. \\
+ \textsl{\code{fsync}} & sincronizza il contenuto del file (vedi
+ \secref{sec:file_sync}). \\
+ \textsl{\code{fasync}} & abilita l'I/O asincrono (vedi
+ \secref{sec:file_asyncronous_io}) sul file. \\
\hline
\end{tabular}
\caption{Operazioni sui file definite nel VFS.}
\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}
\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}
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
\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}
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
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