From: Simone Piccardi Date: Sun, 28 Oct 2001 22:43:00 +0000 (+0000) Subject: revisioni varie X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=0726315ca76d6655e232a0fafd82d524d133187d;p=gapil.git revisioni varie --- diff --git a/filedir.tex b/filedir.tex index b5eb2c2..f5261b3 100644 --- a/filedir.tex +++ b/filedir.tex @@ -781,19 +781,18 @@ corrente. In tal caso si avranno differenti risultati a seconda del modi in cui si calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si -legge dal file (ad esempio usando \cmd{wc -c}), dato che in tal caso per le -parti non scritte vengono restituiti degli zeri, si avrà lo stesso risultato -di \cmd{ls}. - -Se è sempre possibile allargare un file scrivendoci sopra od usando la -funzione \func{seek} (vedi \secref{sec:file_seek}) per spostarsi oltre la sua -fine. Esistono però anche casi in cui si può avere bisogno di effettuare un -troncamento scartando i dati al di là della dimensione scelta come nuova fine -del file. - -Un file può essere troncato a zero aprendolo con il flag \macro{O\_TRUNC}, ma -questo è un caso particolare; per qualunque altra dimensione si possono usare -le due funzioni: +legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal +caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso +risultato di \cmd{ls}. + +Se è sempre possibile allargare un file, scrivendoci sopra od usando la +funzione \func{seek} per spostarsi oltre la sua fine, esistono anche casi in +cui si può avere bisogno di effettuare un troncamento, scartando i dati +presenti al di là della dimensione scelta come nuova fine del file. + +Un file può sempre essere troncato a zero aprendolo con il flag +\macro{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra +dimensione si possono usare le due funzioni: \begin{functions} \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad @@ -803,9 +802,9 @@ le due funzioni: eccetto che si usa con un file aperto, specificato tramite il suo file descriptor \var{fd}. - Le funzioni restituiscono zero in caso di successo e -1 per un errore, in - caso di errore \var{errno} viene settato opportunamente; per - \func{ftruncate} si hanno i valori: + Le funzioni restituiscono zero in caso di successo e -1 per un errore, nel + qual caso \var{errno} viene settato opportunamente; per \func{ftruncate} si + hanno i valori: \begin{errlist} \item \macro{EBADF} \var{fd} non è un file descriptor. \item \macro{EINVAL} \var{fd} è un riferimento ad un socket, non a un file @@ -825,17 +824,17 @@ Se il file perduti; il comportamento in caso di lunghezza inferiore non è specificato e dipende dall'implementazione: il file può essere lasciato invariato o esteso fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con -zeri (e in genere si ha la creazione di un hole nel file). +zeri (e in genere si ha la creazione di un \textit{hole} nel file). \subsection{I tempi dei file} \label{sec:file_file_times} Il sistema mantiene per ciascun file tre tempi. Questi sono registrati -nell'inode insieme agli altri attributi del file e possono essere letti tramite -la funzione \func{stat}, che li restituisce attraverso tre campi della -struttura in \figref{fig:file_stat_struct}. Il significato di detti tempi e -dei relativi campi è riportato nello schema in \ntab: +nell'inode insieme agli altri attributi del file e possono essere letti +tramite la funzione \func{stat}, che li restituisce attraverso tre campi della +struttura \var{stat} di \figref{fig:file_stat_struct}. Il significato di detti +tempi e dei relativi campi è riportato nello schema in \ntab: \begin{table}[htb] \centering @@ -858,7 +857,7 @@ dei relativi campi Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di -cambiamento di stato (il \textit{chage time} \var{st\_ctime}). Il primo +cambiamento di stato (il \textit{change time} \var{st\_ctime}). Il primo infatti fa riferimento ad una modifica del contenuto di un file, mentre il secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la funzione \func{link} e molte altre che vedremo in seguito) che modificano solo @@ -867,9 +866,9 @@ l'utilizzo di un altro tempo. Il sistema non tiene conto dell'ultimo accesso all'inode, pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il -tempo di ultimo accesso viene di solito usato per cancellare i file che non -servono più dopo un certo lasso di tempo (ad esempio \cmd{leafnode} cancella i -vecchi articoli sulla base di questo tempo). +tempo di ultimo accesso (ai dati) viene di solito usato per cancellare i file +che non servono più dopo un certo lasso di tempo (ad esempio \cmd{leafnode} +cancella i vecchi articoli sulla base di questo tempo). Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere quali file necessitano di essere ricompilati o (talvolta insieme anche al @@ -882,14 +881,15 @@ L'effetto delle varie funzioni di manipolazione dei file sui tempi illustrato in \ntab. Si sono riportati gli effetti sia per il file a cui si fa riferimento, sia per la directory che lo contiene; questi ultimi possono essere capiti se si tiene conto di quanto già detto, e cioè che anche le -directory sono files, che il sistema tratta in maniera del tutto analoga agli -altri. +directory sono file (che contengono una lista di nomi) che il sistema tratta +in maniera del tutto analoga a tutti gli altri. Per questo motivo tutte le volte che compiremo una operazione su un file che -comporta una modifica della sua directory entry, andremo anche a scrivere -sulla directory che lo contiene cambiandone il tempo di modifica. Un esempio -di questo può essere la cancellazione di un file, mentre leggere o scrivere o -cambiarne i permessi ha effetti solo sui tempi del file. +comporta una modifica del nome contenuto nella directory, andremo anche a +scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un +esempio di questo può essere la cancellazione di un file, invece leggere o +scrivere o cambiare i permessi di un file ha effetti solo sui tempi di +quest'ultimo. \begin{table}[htb] \centering @@ -963,7 +963,7 @@ cambiarne i permessi ha effetti solo sui tempi del file. \end{table} Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di -creazione del file, usato da molti altri sistemi operativi, che in unix non +creazione del file, usato in molti altri sistemi operativi, ma che in unix non esiste. @@ -1008,9 +1008,8 @@ volte che si modifica l'inode (quindi anche alla chiamata di \func{utime}). Questo serve anche come misura di sicurezza per evitare che si possa modificare un file nascondendo completamente le proprie tracce. In realtà la cosa resta possibile, se si è in grado di accedere al device, scrivendo -direttamente sul disco senza passare attraverso il filesystem, ma ovviamente è -molto più complicato da realizzare. - +direttamente sul disco senza passare attraverso il filesystem, ma ovviamente +in questo modo la cosa è molto più complicata da realizzare. @@ -1168,7 +1167,7 @@ di accesso sono i seguenti: all'amministratore) l'accesso è sempre garantito senza nessun ulteriore controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a tutti i file. -\item Se l'\textit{effective user id} del processo è uguale all'uid del +\item Se l'\textit{effective user id} del processo è uguale all'\acr{uid} del proprietario del file (nel qual caso si dice che il processo è proprietario del file) allora: \begin{itemize} diff --git a/gapil.tex b/gapil.tex index 2e3e44c..3ecb745 100644 --- a/gapil.tex +++ b/gapil.tex @@ -1,4 +1,4 @@ -%% +%% %% GaPiL : Guida alla Programmazione in Linux %% %% S. Piccardi Oct. 2000 diff --git a/prochand.tex b/prochand.tex index 90e2e9f..4a03b94 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1609,24 +1609,22 @@ Gli utenti normali possono settare l'\textit{effective id} solo al valore del \textit{real id} o del \textit{saved id}, l'amministratore può specificare qualunque valore. Queste funzioni sono usate per permettere a root di settare solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta -il settagio di tutti gli identificatori. +il settaggio di tutti gli identificatori. - \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}} \label{sec:proc_setfsuid} Queste funzioni sono usate per settare gli identificatori usati da Linux per il controllo dell'accesso ai file. Come già accennato in -\secref{sec:proc_user_group} Linux definisce questo ulteriore gruppo di -identificatori che di norma sono assolutamente equivalenti agli -\textit{effective id} (ed in seguito faremo sempre riferimento a questi -ultimi), dato che ogni cambiamento di questi ultimi viene immediatamente -riportato sui \textit{filesystem id}. +\secref{sec:proc_user_group} in Linux è definito questo ulteriore gruppo di +identificatori, che di norma sono assolutamente equivalenti agli +\textit{effective id}, dato che ogni cambiamento di questi ultimi viene +immediatamente riportato sui \textit{filesystem id}. C'è un solo caso in cui si ha necessità di introdurre una differenza fra -\textit{effective id} e i \textit{filesystem id}, che è per ovviare ad un -problema di sicurezza che si presneta quando si deve implementare un server +\textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un +problema di sicurezza che si presenta quando si deve implementare un server NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai file per assumere l'identità del singolo utente remoto, ma se questo viene fatto cambiando l'\textit{effective id} o il \textit{real id} il server si @@ -1636,8 +1634,8 @@ ha temporaneamente assunto l'identit quelli originari per quanto riguarda tutti gli altri controlli di accesso. Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid} -e \func{setfsgid}, sono specifiche di Linux e non devono essere usate se si -intendono scrivere programmi portabili; i loro prototipi sono: +e \func{setfsgid}, ovviamenete sono specifiche di Linux e non devono essere +usate se si intendono scrivere programmi portabili; i loro prototipi sono: \begin{functions} \headdecl{sys/fsuid.h} @@ -1653,9 +1651,8 @@ l'unico errore possibile \end{functions} Queste funzioni hanno successo solo se il processo chiamante ha i privilegi di -amministratore o se il valore specificato coincide con uno dei -\textit{real}, \textit{effective} o \textit{saved id}. - +amministratore o, per gli altri utenti, se il valore specificato coincide con +uno dei \textit{real}, \textit{effective} o \textit{saved id}. @@ -1668,21 +1665,17 @@ occorre tenere conto di tutta una serie di problematiche che normalmente non esistono quando si ha a che fare con un sistema in cui viene eseguito un solo programma alla volta. - Pur non essendo tutto questo direttamente legato alla modalità specifica in -cui il multitasking è implementato in un sistema unix-like, avendo affrontato -la gestione dei processi in questo capitolo, tratteremo queste problematiche, -e relative precauzioni ed accorgimenti, in questa sezione conclusiva. +cui il multitasking è implementato in un sistema unix-like, siccome la +gestione dei processi è stata affrontata in questo capitolo, tratteremo in +questa sezione conclusiva anche queste problematiche, esaminandone le +caratteristiche fondamentali e le modalità con cui si affrontano. \subsection{Le funzioni rientranti} \label{sec:proc_reentrant} -\subsection{I \textit{deadlock}} -\label{sec:proc_deadlock} - - \subsection{Le operazioni atomiche} \label{sec:proc_atom_oper} @@ -1699,3 +1692,6 @@ fonti di errori molto subdoli, che possono verificarsi solo in condizioni particolari e quindi difficilmente riproducibili. +\subsection{I \textit{deadlock}} +\label{sec:proc_deadlock} +