+Grazie a questi identificativi il sistema è in grado di tenere traccia
+dell'utente a cui appartiene ciascun processo ed impedire ad altri utenti di
+interferire con quest'ultimo. Inoltre con questo sistema viene anche
+garantita una forma base di sicurezza interna in quanto anche l'accesso ai
+file (vedi sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo
+di identificazione.
+
+Infine in ogni sistema unix-like è presente uno speciale utente privilegiato,
+il cosiddetto \textit{superuser}, il cui username è di norma \textit{root}, ed
+il cui \ids{UID} è zero. Esso identifica l'amministratore del sistema, che
+deve essere in grado di fare qualunque operazione; per l'utente \textit{root}
+infatti i meccanismi di controllo cui si è accennato in precedenza sono
+disattivati.\footnote{i controlli infatti vengono eseguiti da uno pseudo-codice
+ del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
+
+
+\section{L'architettura di file e directory}
+\label{sec:intro_file_dir}
+
+Come accennato in sez.~\ref{sec:intro_base_concept} uno dei concetti
+fondamentali dell'architettura di un sistema Unix è il cosiddetto
+\textit{everything is a file} (\textsl{tutto è un file}), cioè il fatto che
+l'accesso ai vari dispositivi di input/output del computer viene effettuato
+attraverso un'interfaccia astratta che tratta le periferiche allo stesso modo
+dei normali file di dati.
+
+In questa sezione forniremo una descrizione a grandi linee dell'architettura
+della gestione dei file in Linux, partendo da una introduzione ai concetti di
+base, per poi illustrare la struttura dell'albero dei file ed il significato
+dei tipi di file, concludendo con una panoramica sulle caratteristiche
+principali delle due interfacce con cui i processi possono effettuare l'I/O su
+file.
+
+
+\subsection{Una panoramica generale}
+\label{sec:file_arch_overview}
+
+Per poter accedere ai file, il kernel deve mettere a disposizione dei
+programmi delle opportune \textit{system call} che consentano di leggere e
+scrivere il contenuto. Tutto ciò ha due aspetti: il primo è che il kernel, per
+il concetto dell'\textit{everything is a file}, deve fornire una interfaccia
+che consenta di operare sui file, sia che questi corrispondano ai normali file
+di dati, o ai cosiddetti ``\textsl{file speciali}'', come i file di
+dispositivo (o \textit{device file}) che permettono di accedere alle
+periferiche o le \textit{fifo} ed i socket che forniscono funzionalità di
+comunicazione fra processi (torneremo su questo in sez.~\ref{sec:file_mknod}).
+
+Il secondo aspetto è che per poter utilizzare dei normali file di dati il
+kernel deve provvedere ad organizzare e rendere accessibile in maniera
+opportuna l'informazione in essi contenuta memorizzandola sullo spazio grezzo
+disponibile sui dischi. Questo viene fatto strutturando l'informazione sul
+disco attraverso quello che si chiama un
+``\textit{filesystem}''. L'informazione così strutturata poi viene resa
+disponibile ai processi attraverso quello che viene chiamato il
+``\textsl{montaggio}'' del filesystem nell'albero dei file, dove il contenuto
+sarà accessibile nella forma ordinaria di file e directory.
+
+\itindbeg{Virtual~File~System~(VFS)}
+
+In Linux il concetto di \textit{everything is a file} è stato implementato
+attraverso il cosiddetto \textit{Virtual File System} (da qui in avanti VFS)
+che è uno strato intermedio che il kernel usa per accedere ai più svariati
+filesystem mantenendo la stessa interfaccia per i programmi in \textit{user
+ space}. Il VFS fornisce quel livello di astrazione che permette di
+collegare le operazioni interne del kernel per la manipolazione sui file con
+le \textit{system call} relative alle operazioni di I/O, e gestisce poi
+l'organizzazione di dette operazioni nei vari modi in cui i diversi filesystem
+le effettuano, permettendo la coesistenza di filesystem differenti all'interno
+dello stesso albero delle directory. Approfondiremo il funzionamento di
+interfaccia generica fornita dal VFS in sez.~\ref{sec:file_vfs_work}.
+
+In sostanza quello che accade è che quando un processo esegue una
+\textit{system call} che opera su un file, il kernel chiama sempre una
+funzione implementata nel VFS. La funzione eseguirà le manipolazioni sulle
+strutture generiche e utilizzerà poi delle chiamate alle opportune funzioni
+del filesystem specifico a cui si fa riferimento. Saranno queste infine a
+chiamare le funzioni di più basso livello che eseguono le operazioni di I/O
+sul dispositivo fisico, secondo lo schema riportato in
+fig.~\ref{fig:file_VFS_scheme}.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=8cm]{img/vfs}
+ \caption{Schema delle operazioni del VFS.}
+ \label{fig:file_VFS_scheme}
+\end{figure}
+
+Questa interfaccia resta la stessa anche quando, invece che a dei normali
+file, si accede alle periferiche coi citati file di dispositivo, solo che in
+questo caso invece di usare il codice del filesystem che accede al disco, il
+\textit{Virtual File System} eseguirà direttamente il codice del kernel che
+permette di accedere alla periferica.
+
+\itindend{Virtual~File~System~(VFS)}
+
+Come accennato in precedenza una delle funzioni essenziali per il
+funzionamento dell'interfaccia dei file è quella che consente di montare un
+filesystem nell'albero dei file, e rendere così visibili i suoi contenuti. In
+un sistema unix-like infatti, a differenza di quanto avviene in altri sistemi
+operativi, tutti i file vengono mantenuti all'interno di un unico albero la
+cui radice (quella che viene chiamata \textit{root directory}) viene montata
+all'avvio direttamente dal kernel.
+
+Come accennato in sez.~\ref{sec:intro_kern_and_sys}) montare la radice è,
+insieme al lancio di \cmd{init},\footnote{l'operazione è ovviamente anche
+ preliminare al lancio di \cmd{init}, dato il kernel deve poter accedere al
+ file che contiene detto programma.} l'unica operazione che viene effettuata
+direttamente dal kernel in fase di avvio. Il kernel infatti, completata la
+fase di inizializzazione, utilizza l'indicazione passatagli dal
+\textit{bootloader} su quale sia il dispositivo che contiene il filesystem da
+usare come punto di partenza, lo monta come radice dell'albero dei file.
+
+Tutti gli ulteriori filesystem che possono essere disponibili su altri
+dispositivi dovranno a loro volta essere inseriti nell'albero, montandoli in
+altrettante directory del filesystem radice, su quelli che vengono chiamati
+\textit{mount point}. Questo comunque avverrà sempre in un secondo tempo, a
+cura dei programmi eseguiti nella procedura di inizializzazione del sistema,
+grazie alle funzioni che tratteremo in sez.~\ref{sec:filesystem_mounting}.
+
+
+\subsection{La risoluzione del nome di file e directory}
+\label{sec:file_pathname}
+
+\itindbeg{pathname}
+
+Come appena illustrato sez.~\ref{sec:file_arch_overview} una delle
+caratteristiche distintive di un sistema unix-like è quella di avere un unico
+albero dei file. Un file deve essere identificato dall'utente usando quello
+che viene chiamato il suo \textit{pathname},\footnote{il manuale della
+ \acr{glibc} depreca questa nomenclatura, che genererebbe confusione poiché
+ \textit{path} indica anche un insieme di directory su cui effettuare una
+ ricerca (come quello in cui la shell cerca i comandi). Al suo posto viene
+ proposto l'uso di \textit{filename} e di componente per il nome del file
+ all'interno della directory. 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.} vale a dire tramite il
+``\textsl{percorso}'' (nome che talvolta viene usato come traduzione di
+\textit{pathname}) che si deve fare per accedere al file a partire da una
+certa ``\textit{directory}''.
+
+Una directory in realtà è anch'essa un file, nel senso che è anch'essa un
+oggetto di un filesystem, solo che è un file particolare che il kernel
+riconosce appositamente come tale per poterlo utilizzare come directory. Il
+suo scopo è quello di contenere una lista di nomi di file e le informazioni
+che associano ciascuno di questi nomi al relativo contenuto (torneremo su
+questo in sez.~\ref{sec:file_arch_func}).
+
+Dato che questi nomi possono corrispondere ad un qualunque altro oggetto del
+filesystem, compresa un'altra directory, si ottiene naturalmente
+un'organizzazione ad albero inserendo nomi di directory dentro altre
+directory. All'interno dello stesso albero si potranno poi inserire anche
+tutti gli altri oggetti previsti l'interfaccia del VFS (su cui torneremo in
+sez.~\ref{sec:file_file_types}), come le \textit{fifo}, i collegamenti
+simbolici, i socket e gli stessi file di dispositivo.
+
+La convenzione usata nei sistemi unix-like per indicare i \textit{pathname}
+dei file è quella di usare il carattere ``\texttt{/}'' come separatore fra i
+nomi che indicano le directory che lo compongono. Dato che la directory radice
+sta in cima all'albero, essa viene indicata semplicemente con il
+\textit{pathname} ``\file{/}''.
+
+\itindbeg{pathname~resolution}
+
+Un file può essere indicato rispetto ad una directory semplicemente
+specificandone il nome, il manuale della \acr{glibc} chiama i nomi contenuti
+nelle directory ``componenti'' (in inglese \textit{file name components}), noi
+li chiameremo più semplicemente \textsl{nomi} o \textsl{voci}, riservando la
+parola \textsl{componenti} ai nomi che, separati da una ``\texttt{/}'',
+costituiscono il \textit{pathname}. Questi poi dovranno corrispondere, perché
+il \textit{pathname} sia valido, a voci effettivamente presenti nelle
+directory, ma non è detto che un \textit{pathname} debba per forza risultare
+valido.
+
+Il procedimento con cui dato un \textit{pathname} si individua il file a cui
+esso fa riferimento, è chiamato \textsl{risoluzione del percorso}
+(\textit{filename resolution} o \textit{pathname resolution}). Lo stesso
+procedimento ci può anche dire che il \textit{pathname} usato non è valido.
+La risoluzione viene eseguita esaminando il \textit{pathname} da sinistra a
+destra e localizzando ogni componente dello stesso come nome in una directory
+a partire dalla directory iniziale, usando il carattere ``\texttt{/}'' come
+separatore per scendere dall'una all'altra. Nel caso si indichi un componente
+vuoto il costrutto ``\texttt{//}'' viene considerato equivalente a
+``\texttt{/}''.
+
+Ovviamente perché la risoluzione abbia successo occorre che i componenti
+intermedi esistano e siano effettivamente directory, e che il file o la
+directory indicata dall'ultimo componente esista. Inoltre i permessi relativi
+alle directory indicate nel \textit{pathname} (torneremo su questo
+sez.~\ref{sec:file_access_control}) dovranno consentire l'accesso all'intero
+\textit{pathname}.
+
+\itindsubbeg{pathname}{assoluto}
+\itindsubbeg{pathname}{relativo}
+
+Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
+parte dalla directory radice del processo. Questa, a meno di non avere
+eseguito una \func{chroot} (funzione su cui torneremo in
+sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
+directory radice dell'albero dei file montata dal kernel all'avvio del
+sistema; in questo caso si parla di un \textsl{pathname assoluto}. Altrimenti
+la ricerca parte dalla directory di lavoro corrente del processo (su cui
+torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
+\textsl{pathname relativo}.
+
+\itindsubend{pathname}{assoluto}
+\itindsubend{pathname}{relativo}
+
+Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
+speciale e vengono inseriti in ogni directory quando questa viene creata (vedi
+sez.~\ref{sec:file_dir_creat_rem}). Il primo fa riferimento alla directory
+corrente e il secondo alla directory \textsl{genitrice} (o \textit{parent
+ directory}) cioè la directory che contiene il riferimento alla directory
+corrente.
+
+In questo modo con ``\file{..}'' si può usare un \textit{pathname} relativo
+per indicare un file posto al di sopra della directory corrente, tornando
+all'indietro nell'albero dei file. Questa retromarcia però su fermerà una
+volta raggiunta la directory radice, perché non esistendo in questo caso una
+directory superiore, il nome ``\file{..}'' farà riferimento alla radice
+stessa.
+
+\itindend{pathname}
+\itindend{pathname~resolution}
+
+
+\subsection{I tipi di file}
+\label{sec:file_file_types}
+
+Parlare dei tipi di file su Linux, come per qualunque sistema unix-like,
+significa anzitutto chiarire il proprio vocabolario e sottolineare le
+differenze che ci sono rispetto ad altri sistemi operativi.
+
+\index{file!di~dispositivo|(}
+\index{file!speciali|(}
+
+Come accennato in sez.~\ref{sec:file_arch_overview} su Linux l'uso del
+\textit{Virtual File System} consente di trattare come file oggetti molto
+diversi fra loro. Oltre ai normali file di dati abbiamo già accennato ad altri
+due di questi oggetti, i file di dispositivo e le directory, ma ne esistono
+altri. In genere quando si parla di tipo di file su Linux si fa riferimento a
+questi diversi tipi, di cui si riportato l'elenco completo in
+tab.~\ref{tab:file_file_types}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|l|p{6cm}|}
+ \hline
+ \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \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{inode} (vedi
+ sez.~\ref{sec:file_vfs_work}).\\
+ \textit{symbolic link}&\textsl{collegamento simbolico}
+ & Un file che contiene un riferimento ad un altro
+ file/directory.\\
+ \textit{char device} &\textsl{dispositivo a caratteri}
+ & Un file \textsl{speciale} che identifica una
+ periferica ad accesso a caratteri.\\
+ \textit{block device}& \textsl{dispositivo a blocchi}
+ & Un file \textsl{speciale} che identifica una
+ periferica ad accesso a blocchi.\\
+ \textit{fifo} & ``\textsl{coda}''
+ & Un file \textsl{speciale} che identifica una
+ linea di comunicazione unidirezionale (vedi
+ sez.~\ref{sec:ipc_named_pipe}).\\
+ \textit{socket} & ``\textsl{presa}''
+ & Un file \textsl{speciale} che identifica una
+ linea di comunicazione bidirezionale (vedi
+ cap.~\ref{cha:socket_intro}).\\
+ \hline
+ \end{tabular}
+ \caption{Tipologia dei file definiti nel VFS}
+ \label{tab:file_file_types}
+\end{table}
+
+Si tenga ben presente che questa classificazione non ha nulla a che fare con
+una classificazione dei file in base al loro contenuto, dato che in tal caso
+si avrebbe a che fare sempre e solo con dei file di dati. E non ha niente a
+che fare neanche con le eventuali diverse modalità con cui si possa accedere
+al contenuto dei file di dati. La classificazione di
+tab.~\ref{tab:file_file_types} riguarda il tipo di oggetti gestiti dal
+\textit{Virtual File System}, ed è da notare la presenza dei cosiddetti file
+``\textsl{speciali}''.
+
+Alcuni di essi, come le \textit{fifo} (che tratteremo in
+sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
+cap.~\ref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
+alcune funzionalità di comunicazione fornite dal kernel. Gli altri sono
+proprio quei \textsl{file di dispositivo} che costituiscono una interfaccia
+diretta per leggere e scrivere sui dispositivi fisici. Anche se finora li
+abbiamo chiamati genericamente così, essi sono tradizionalmente 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.
+
+I dispositivi a blocchi (ad esempio i dischi) sono quelli corrispondono a
+periferiche per le quali è richiesto che l'I/O venga effettuato per blocchi di
+dati di dimensioni fissate (nel caso dei dischi le dimensioni di un settore),
+mentre i dispositivi a caratteri sono quelli per cui l'I/O può essere
+effettuato senza nessuna particolare struttura, ed in generale anche un byte
+alla volta, da cui il nome.
+
+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. Non c'è neanche una strutturazione a
+record per il cosiddetto ``\textsl{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 delle 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 ma ormai in sostanziale disuso.}
+
+\index{file!di~dispositivo|)}
+\index{file!speciali|)}
+
+Una differenza che attiene ai contenuti di un file però esiste, ed è relativa
+al formato dei file di testo. Nei sistemi unix-like la fine riga è codificata
+in maniera diversa da Windows o dal vecchio MacOS, in particolare il fine riga
+è il carattere \texttt{LF} (\verb|\n|) al posto del \texttt{CR} (\verb|\r|)
+del vecchio MacOS e del \texttt{CR LF} (\verb|\r\n|) di Windows. Questo può
+causare alcuni problemi qualora nei programmi si facciano assunzioni sul
+terminatore della riga e per questo esistono dei programmi come \cmd{unix2dos}
+e \cmd{dos2unix} che effettuano una conversione fra questi due formati di
+testo.
+
+Si ricordi comunque che un kernel unix-like non fornisce nessun supporto per
+la tipizzazione dei file di dati in base al loro contenuto e che non c'è
+nessun supporto per una qualche interpretazione delle estensioni (nel nome del
+file) da parte del kernel,\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 esiste la possibilità di associare delle risorse ai
+ file con gli \textit{extended attributes} (vedi sez.~\ref{sec:file_xattr}),
+ ma è una caratteristica tutt'ora poco utilizzata, dato che non corrisponde
+ al modello classico dei file in un sistema Unix.} ogni classificazione di
+questo tipo avviene sempre in \textit{user space}. Gli unici file di cui il
+kernel deve essere in grado di capire il contenuto sono i binari dei
+programmi, per i quali sono supportati solo alcuni formati, anche se oggi
+viene usato quasi esclusivamente
+\itindex{Executable~and~Linkable~Format~(ELF)} l'ELF.\footnote{il nome è
+ l'acronimo di \textit{Executable and Linkable Format}, un formato per
+ eseguibili binari molto flessibile ed estendibile definito nel 1995 dal
+ \textit{Tool Interface Standard} che per le sue caratteristiche di non
+ essere legato a nessun tipo di processore o architettura è stato adottato da
+ molti sistemi unix-like e non solo.}
+
+\itindbeg{magic~number}
+
+Nonostante l'assenza di supporto da parte del kernel per la classificazione
+del contenuto dei file di dati, molti programmi adottano comunque delle
+convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
+in file con l'estensione ``\file{.c}''. Inoltre una tecnica molto usata per
+classificare i contenuti da parte dei programmi è quella di utilizzare i primi
+byte del file per memorizzare un ``\textit{magic number}'' che ne classifichi
+il contenuto. Il concetto è quello di un numero intero, solitamente fra 2 e 10
+byte, che identifichi il contenuto seguente, dato che questi sono anche
+caratteri è comune trovare espresso tale numero con stringhe come
+``\texttt{\%PDF}'' per i PDF o ``\texttt{\#!}'' per gli script. Entrambe
+queste tecniche, per quanto usate ed accettate in maniera diffusa, restano
+solo delle convenzioni il cui rispetto è demandato alle applicazioni stesse.
+
+\itindend{magic~number}
+
+
+\subsection{Le due interfacce per l'accesso ai file}
+\label{sec:file_io_api}
+
+
+\itindbeg{file~descriptor}
+
+In Linux le interfacce di programmazione per l'I/O su file due. La prima è
+l'interfaccia nativa del sistema, quella che il manuale della \textsl{glibc}
+chiama interfaccia dei ``\textit{file descriptor}'' (in italiano
+\textsl{descrittori di file}). Si tratta di un'interfaccia specifica dei
+sistemi unix-like che fornisce un accesso non bufferizzato.
+
+L'interfaccia è essenziale, l'accesso viene detto non bufferizzato in quanto
+la lettura e la scrittura vengono eseguite chiamando direttamente le
+\textit{system call} del kernel, anche se in realtà il kernel effettua al suo
+interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
+dispositivi. L'accesso viene gestito attraverso i \textit{file descriptor} che
+sono rappresentati da numeri interi (cioè semplici variabili di tipo
+\ctyp{int}). L'interfaccia è definita nell'\textit{header file}
+\headfile{unistd.h} e la tratteremo in dettaglio in
+sez.~\ref{sec:file_unix_interface}.
+
+\itindbeg{file~stream}
+
+La seconda interfaccia è quella che il manuale della \acr{glibc} chiama dei
+\textit{file stream} o più semplicemente degli \textit{stream}.\footnote{in
+ realtà una interfaccia con lo stesso nome è stata introdotta a livello di
+ kernel negli Unix derivati da \textit{System V}, come strato di astrazione
+ per file e socket; in Linux questa interfaccia, che comunque ha avuto poco
+ successo, non esiste, per cui facendo riferimento agli \textit{stream}
+ useremo il significato adottato dal manuale della \acr{glibc}.} Essa
+fornisce funzioni più evolute e un accesso bufferizzato, controllato dalla
+implementazione fatta nella \acr{glibc}. Questa è l'interfaccia specificata
+dallo standard ANSI C e perciò si trova 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, a cui si accede sempre in
+maniera indiretta utilizzando il tipo \code{FILE *}; l'interfaccia è definita
+nell'\textit{header file} \headfile{stdio.h} e la tratteremo in dettaglio in
+sez.~\ref{sec:files_std_interface}.
+
+Entrambe le interfacce possono essere usate per l'accesso ai file come agli
+altri oggetti del VFS, ma per poter accedere alle operazioni di controllo
+(descritte in sez.~\ref{sec:file_fcntl_ioctl}) su un qualunque tipo di oggetto
+del VFS occorre usare l'interfaccia standard di Unix con i file
+descriptor. Allo stesso modo devono essere usati i file descriptor se si vuole
+ricorrere a modalità speciali di I/O come il \textit{file locking} o l'I/O
+non-bloccante (vedi cap.~\ref{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 è molto più ricca di
+quella dei \textit{file descriptor}, che forniscono 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 \textit{stream} sono implementati sopra
+l'interfaccia standard di Unix, è sempre possibile estrarre il \textit{file
+ descriptor} da uno \textit{stream} ed eseguirvi sopra operazioni di basso
+livello, o associare in un secondo tempo uno \textit{stream} ad un
+\textit{file descriptor} per usare l'interfaccia più sofisticata.
+
+In generale, se non necessitano specificatamente le funzionalità di basso
+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.
+
+\itindend{file~descriptor}
+\itindend{file~stream}
+
+\section{Gli standard}