operazioni direttamente sulle periferiche, usando le stesse funzioni che si
usano per i normali file di dati.
-In questo capitolo forniremo una panoramica dell'architettura dei file, sia
-nelle sue caratteristiche generali, comuni a tutti gli Unix, che nelle
-particolarità che ha la specifica implementazione usata da Linux.
+In questo capitolo forniremo una descrizione dell'architettura dei file in
+Linux, iniziando da una panoramica sulle caratteristiche principali delle
+interfacce con cui i processi accedono ai file (che tratteremo in dettaglio
+nei capitoli seguenti), per poi passare ad una descrizione più dettagliata
+delle modalità con cui detto accesso viene realizzato dal sistema.
-\section{L'architettura dell'accesso ai file}
+\section{L'architettura generale}
\label{sec:file_access_arch}
Per poter accedere ai file il kernel deve mettere a disposizione dei programmi
cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna
l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene
fatto strutturando l'informazione sul disco attraverso quello che si chiama un
-\textit{filesystem}, essa poi viene resa disponibile attraverso quello che
-viene chiamato il \textsl{montaggio} del filesystem.
+\textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi viene resa
+disponibile ai processi attraverso quello che viene chiamato il
+\textsl{montaggio} del \textit{filesystem}.
% (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
In questa sezione faremo una panormamica generica su come il sistema presenta
i file ai processi, trattando l'organizzazione di file e directory, i tipi di
-file ed introducendo le interfacce disponibili, che saranno approfondite nei
-capitoli seguenti.
+file ed introducendo le interfacce disponibili e le loro caratteristiche.
\subsection{L'organizzazione di file e directory}
-\label{sec:file_file_struct}
+\label{sec:file_organization}
In Unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
file vengono tenuti all'interno di un unico albero la cui radice (quella che
-viene chiamata \textit{root directory}) viene montata all'avvio. Pertanto
-un file viene identificato dall'utente usando quello che viene chiamato
-\textit{pathname}, cioè il percorso che si deve fare per accedere al file.
-
-Dopo la fase di inizializzazione il kernel riceve dal boot loader
-l'indicazione di quale dispositivo contiene il filesystem da usare come punto
-di partenza e questo viene montato come radice dell'albero (cioè nella
-directory \file{/}); tutti gli ulteriori filesystem che possono essere su
-altri dispositivi devono poi essere inseriti nell'albero utilizzando opportune
-subdirectory.
+viene chiamata \textit{root directory}) viene montata all'avvio. Un file
+viene identificato dall'utente usando quello che viene chiamato
+\textit{pathname}\footnote{anche se il manuale della \acr{glibc} depreca
+ questa nomenclatura, poiché genererebbe confusione, dato che con
+ \textit{path} si indica anche un insieme di directory su cui effettuare una
+ ricerca (come quello in cui si cercano i comandi) non seguiremo questa
+ scelta dato che l'uso della parola \textit{pathname} è ormai così comune che
+ mantenerne l'uso è senz'altro più chiaro dell'alternativa proposta.}, cioè
+il percorso che si deve fare per accedere al file a partire dalla \textit{root
+ directory}, che è composto da una serie di nomi separati da una \file{/}.
+
+All'avvio del sistema, comletata la fase di inizializzazione il kernel riceve
+dal boot loader l'indicazione di quale dispositivo contiene il filesystem da
+usare come punto di partenza e questo viene montato come radice dell'albero
+(cioè nella directory \file{/}); tutti gli ulteriori filesystem che possono
+essere su altri dispositivi dovranno poi essere inseriti nell'albero
+montandoli su opportune directory del filesystem montato come radice.
Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
alcune strutture interne del kernel) sono generati automaticamente dal kernel
-stesso, ma anche essi devono essere montati all'interno dell'albero.
-
-All'interno dello stesso albero si potranno poi inserire anche gli altri
-oggetti visti attraverso l'interfaccia che manipola i file come le fifo, i
-link, i socket e gli stessi i file di dispositivo (questi ultimi, per
-convenzione, sono inseriti nella directory \file{/dev}).
-
-L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
-medesimi nell'albero descritto in precedenza; una directory comunque, come
-vedremo in \secref{sec:file_vfs_work}, è solo un particolare tipo di file che
-contiene le informazioni che associano un nome al contenuto.
-
-% Per questo, anche se è usuale parlare di ``file in una directory'' in realtà
-% una directory contiene solo delle etichette per fare riferimento ai file
-% stessi.
-
-I manuale delle \acr{glibc} chiama i nomi contenuti nelle directory
-\textsl{componenti} (in inglese \textit{file name components}), noi li
-chiameremo più semplicemente \textit{nomi}. Un file può essere indicato
-rispetto alla directory corrente semplicemente specificando il nome da essa
-contenuto. Una directory contiene semplicemente un elenco di questi nomi, che
-possono corrispondere a un qualunque oggetto del filesystem, compresa un'altra
-directory; l'albero viene appunto creato inserendo directory in altre
-directory.
-
-Il nome completo di file generico è composto da una serie di nomi separati da
-una \file{/} (in Linux più \file{/} consecutive sono considerate equivalenti
-ad una sola). Il nome completo di un file viene usualmente chiamato
-\textit{pathname}, e anche se il manuale della \acr{glibc} depreca questa
-nomenclatura\footnote{poiché genererebbe confusione, dato che con
- \textit{path} si indica anche un insieme di directory su cui effettuare una
- ricerca, come quello in cui si cercano i comandi}; non seguiremo questa
-scelta dato che l'uso della parola \textit{pathname} è ormai così comune che è
-senz'altro più chiaro dell'alternativa proposta.
-
-Il procedimento con cui si associa ad un pathname uno specifico file è
-chiamato risoluzione del nome (\textit{file name resolution} o
-\textit{pathname resolution}). La risoluzione viene fatta esaminando il
-pathname da destra a sinistra e localizzando ogni nome nella directory
-indicata dal nome precedente: ovviamente perché il procedimento funzioni
-occorre che i nomi indicati come directory esistano e siano effettivamente
-directory, inoltre i permessi devono consentire l'accesso.
-
-Se il pathname comincia per \file{/} la ricerca parte dalla directory radice
-del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
-seguito, vedi \secref{sec:file_chroot}) è la stessa per tutti i processi ed
-equivale alla directory radice dell'albero (come descritto in
-\secref{sec:file_organization}): in questo caso si parla di un pathname
-\textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
-cui torneremo più avanti in \secref{sec:file_work_dir}) ed il pathname è
-detto \textsl{relativo}.
+stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
+
+Una directory, come vedremo in maggior dettaglio in
+\secref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
+particolare che il kernel riconosce come tale. Il suo scopo è quello di
+contenere una lista di nomi di file e le informazioni che associano ciascun
+nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
+oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
+un'organizzazione ad albero inserendo directory in altre directory.
+
+Un file può essere indicato rispetto alla directory corrente semplicemente
+specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
+ contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
+ components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
+contenuto. All'interno dello stesso albero si potranno poi inserire anche
+tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file
+come le fifo, i link, i socket e gli stessi i file di dispositivo (questi
+ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
+
+Il nome completo di un file viene chiamato \textit{pathname} ed il
+procedimento con cui si individua il file a cui esso fa riferimento è chiamato
+risoluzione del nome (\textit{file name resolution} o \textit{pathname
+ resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da
+sinistra a destra e localizzando ogni nome nella directory indicata dal nome
+precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
+ costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente
+perché il procedimento funzioni occorre che i nomi indicati come directory
+esistano e siano effettivamente directory, inoltre i permessi (si veda
+\secref{sec:file_access_control}) devono consentire l'accesso.
+
+Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
+radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in
+\secref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
+directory radice dell'albero dei file: in questo caso si parla di un
+\textsl{pathname assoluto}\index{pathname assoluto}. Altrimenti la ricerca
+parte dalla directory corrente (su cui torneremo in
+\secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
+ relativo}\index{pathname relativo}.
I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
in ogni directory, il primo fa riferimento alla directory corrente e il
-secondo alla directory \textsl{genitrice} (\textit{parent directory}) cioè la
-directory che contiene il riferimento alla directory corrente; nel caso questa
-sia la directory radice allora il riferimento è a se stessa.
+secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
+la directory che contiene il riferimento alla directory corrente; nel caso
+questa sia la directory radice allora il riferimento è a se stessa.
\subsection{I tipi di file}
\label{sec:file_file_types}
-Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
+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 Virtual
-File System è riportato in \ntab.
+utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
+\textit{Virtual File System}\index{Virtual File System} è riportato in \ntab.
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
un file che identifica una periferica ad accesso sequenziale \\
\textit{block device} & \textsl{dispositivo a blocchi} &
un file che identifica una periferica ad accesso diretto \\
- \textit{fifo} & \textsl{tubo} &
+ \textit{fifo} & \textsl{``tubo''} &
un file speciale che identifica una linea di comunicazione software
(unidirezionale) \\
- \textit{socket} & \textsl{manicotto} &
+ \textit{socket} & \textsl{``spina''} &
un file speciale che identifica una linea di comunicazione software
(bidirezionale) \\
\hline
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ò 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 \file{.c}, ma questa è, appunto, solo una convenzione.
+
+
\subsection{Le due interfacce ai file}
\label{sec:file_io_api}
-In unix le modalità di accesso ai file e le relative interfacce di
+In Linux le modalità di accesso ai file e le relative interfacce di
programmazione sono due, basate su due diversi meccanismi con cui è possibile
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}). È
-un'interfaccia specifica di unix e provvede un accesso non bufferizzato, la
-tratteremo in dettaglio in \capref{cha:file_unix_interface}.
+La prima è l'interfaccia standard di Unix, quella che il manuale delle
+\acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
+ descriptor}). È un'interfaccia specifica dei sistemi unix-like 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
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 file descriptor sono rappresentati da numeri interi (cioè
-semplici variabili di tipo \type{int}). L'interfaccia è definita
-nell'header \file{unistd.h}.
+dispositivi); i \textit{file descriptor}\index{file descriptor} sono
+rappresentati da numeri interi (cioè semplici variabili di tipo \type{int}).
+L'interfaccia è definita nell'header \file{unistd.h}.
-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), la tratteremo
-in dettaglio in \capref{cha:files_std_interface}.
+La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
+\textit{stream}\index{stream}, essa provvede funzioni più evolute e un accesso
+bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
+tratteremo in dettaglio nel \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
-\type{FILE *}. L'interfaccia è definita nell'header \type{stdio.h}.
+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}.
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio
-a tempo opportuno), ma per poter accedere alle operazioni di controllo sul
-particolare tipo di oggetto del VFS scelto occorre usare l'interfaccia
-standard di unix coi file descriptor. Allo stesso modo devono essere usati i
-file descriptor se si vuole ricorrere a modalità speciali di I/O come il
-polling o il non-bloccante (vedi \secref{sec:file_noblocking}).
-
-Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
-dei file descriptor, che tratta tutti i file nello stesso modo, con
-l'eccezione di poter scegliere tra diversi stili di bufferizzazione. Il
-maggior vantaggio degli stream è che l'interfaccia per le operazioni di
-input/output è enormemente più ricca di quella dei file descriptor, che
-provvedono solo funzioni elementari per la lettura/scrittura diretta di
-blocchi di byte. In particolare gli stream dispongono di tutte le funzioni
-di formattazione per l'input e l'output adatte per manipolare anche i dati in
+a tempo opportuno), ma per poter accedere alle operazioni di controllo su un
+qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix
+coi \textit{file descriptor}. Allo stesso modo devono essere usati i
+\textit{file descriptor} se si vuole ricorrere a modalità speciali di I/O come
+il polling o il non-bloccante (vedi \capref{cha:file_advanced}).
+
+Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
+quella dei \textit{file descriptor}, che permette di poter scegliere tra
+diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream}
+è che l'interfaccia per le operazioni di input/output è enormemente più ricca
+di quella dei \textit{file descriptor}, che provvedono solo funzioni
+elementari per la lettura/scrittura diretta di blocchi di byte. In
+particolare gli \textit{stream} dispongono di tutte le funzioni di
+formattazione per l'input e l'output adatte per manipolare anche i dati in
forma di linee o singoli caratteri.
In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
-standard di unix, è sempre possibile estrarre il file descriptor da uno stream
-ed eseguirvi operazioni di basso livello, o associare in un secondo tempo uno
-stream ad un file descriptor.
+standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
+uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo
+tempo uno \textit{stream} ad un \textit{file descriptor}.
In generale, se non necessitano specificatamente le funzionalità di basso
-livello, è opportuno usare sempre gli stream per la loro maggiore portabilità
-essendo questi ultimi definiti nello standard ANSI C; l'interfaccia con i file
-descriptor invece segue solo lo standard POSIX.1 dei sistemi unix ed è
-pertanto di portabilità più limitata.
-
-
-\subsection{Caratteristiche specifiche dei file in unix}
-\label{sec:fileint_unix_spec}
-
-Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
-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
-creata all'interno del processo una apposita struttura in cui sono memorizzati
-tutti gli attributi del medesimo, che viene utilizzata per tutte le
-operazioni. Questa è una struttura che resta locale al processo stesso; in
-questo modo processi diversi possono usare le proprie strutture locali per
-accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
-indipendente.
-
-Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
-sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
-file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
-successiva. Essa è rappresentata da un numero intero che indica il numero di
-byte dall'inizio del file, che viene (a meno che non si apra il file in
-append) inizializzato a zero all'apertura del medesimo.
-
-Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
-ogni processo avrà la sua posizione corrente nel file, che non sarà
-influenzata da quello che altri processi possono fare. Anzi, aprire un file
-significa appunto creare ed inizializzare una tale struttura, per cui se si
-apre due volte lo stesso file all'interno dello stesso processo, si otterranno
-due file descriptor o due stream che avranno ancora una posizione corrente nel
-file assolutamente indipendente.
-
-Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
-accesso è un riferimento all'inode del file, pertanto anche se il file viene
-cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
-dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
-chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
-in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
-cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
-file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
-saranno disponibili per tutto il tempo in cui il processo è attivo.
-
-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 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.
+livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
+portabilità, essendo questi ultimi definiti nello standard ANSI C;
+l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
+POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
+
+
+% \subsection{Caratteristiche specifiche dei file in Unix}
+% \label{sec:fileint_unix_spec}
+
+% Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
+% 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
+% creata all'interno del processo una apposita struttura in cui sono memorizzati
+% tutti gli attributi del medesimo, che viene utilizzata per tutte le
+% operazioni. Questa è una struttura che resta locale al processo stesso; in
+% questo modo processi diversi possono usare le proprie strutture locali per
+% accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
+% indipendente.
+
+% Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
+% sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
+% file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
+% successiva. Essa è rappresentata da un numero intero che indica il numero di
+% byte dall'inizio del file, che viene (a meno che non si apra il file in
+% append) inizializzato a zero all'apertura del medesimo.
+
+% Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
+% ogni processo avrà la sua posizione corrente nel file, che non sarà
+% influenzata da quello che altri processi possono fare. Anzi, aprire un file
+% significa appunto creare ed inizializzare una tale struttura, per cui se si
+% apre due volte lo stesso file all'interno dello stesso processo, si otterranno
+% due file descriptor o due stream che avranno ancora una posizione corrente nel
+% file assolutamente indipendente.
+
+% Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
+% accesso è un riferimento all'inode del file, pertanto anche se il file viene
+% cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
+% dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
+% chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
+% in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
+% cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
+% file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
+% saranno disponibili per tutto il tempo in cui il processo è attivo.
+
+% Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
+% l'input/output sui file, esaminando in dettaglio come tutto ciò viene
+% realizzato.
\section{L'architettura della gestione dei file}
\label{sec:file_arch_func}
Per capire fino in fondo le proprietà di file e directory in un sistema
-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}.
+unix-like ed il comportamento delle relative funzioni di manipolazione occorre
+una breve introduzione al funzionamento gestione dei file da parte del kernel
+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 file in
Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
-poi in maniera un po' più dettagliata il filesystem standard di Linux,
-l'\acr{ext2}, come esempio di un filesystem unix-like.
+prima le caratteristiche generali di un filesystem Unix, per poi trattare in
+maniera un po' più dettagliata il filesystem standard di Linux, l'\acr{ext2}.
% in particolare si riprenderà, approfondendolo sul piano
projects / gapil.git / blobdiff