X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=15e2fd82fbd77d9004b4fccd7973c75d691d57c7;hp=40d8e2575d262890ff440b6f165c95eb1f563537;hb=9aeb46d93d970f26f1939d3853e4a9e62b2eb5b9;hpb=d4c16890a0197a513327a43fbed7d95c48bee8cb diff --git a/fileintro.tex b/fileintro.tex index 40d8e25..15e2fd8 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -90,10 +90,11 @@ 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 + 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. +\secref{sec:file_access_control}) devono consentire l'accesso all'intero +\textit{pathname}. 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 @@ -105,16 +106,16 @@ parte dalla directory corrente (su cui torneremo in 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 +in ogni directory: 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; nel caso -questa sia la directory radice allora il riferimento è a se stessa. +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 @@ -143,10 +144,10 @@ dati) in base al loro contenuto, o tipo di accesso. 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{``coda''} & un file speciale che identifica una linea di comunicazione software (unidirezionale) \\ - \textit{socket} & \textsl{``spina''} & + \textit{socket} & \textsl{``presa''} & un file speciale che identifica una linea di comunicazione software (bidirezionale) \\ \hline @@ -160,27 +161,28 @@ VMS o Windows) 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 +per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i kernel della serie 2.4 è disponibile una forma di accesso diretto ai dischi (il \textit{raw access}) attraverso dei device file appositi, che però non - ha nulla a che fare con questo}. + ha nulla a che fare con questo.} 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 è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} -(\verb|\r|) del Mac e del \texttt{CR LF} di Windows. Questo può causare alcuni +codificata in maniera diversa da Windows o Mac, in particolare il fine riga è +il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|) +del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux + dei programmi come \cmd{unix2dos} e \cmd{dos2unix} che effettuano una + conversione fra questi due formati di testo.} Questo può causare alcuni 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 +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. - \subsection{Le due interfacce ai file} \label{sec:file_io_api} @@ -203,21 +205,21 @@ rappresentati da numeri interi (cio L'interfaccia è definita nell'header \file{unistd.h}. La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli -\textit{stream}\index{stream}, essa provvede funzioni più evolute e un accesso +\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 \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 +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 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 +con i \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}).