From 5c276f48d2b22a017614dddf8afe47f91af6f628 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Thu, 19 Jan 2012 20:23:57 +0000 Subject: [PATCH] Correzioni varie --- filedir.tex | 250 +++++++++++++++++++++++++++++----------------------- 1 file changed, 138 insertions(+), 112 deletions(-) diff --git a/filedir.tex b/filedir.tex index 757bc13..f11da2c 100644 --- a/filedir.tex +++ b/filedir.tex @@ -138,7 +138,7 @@ questo punto verrà inserita nella cache. Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount} della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry} -iniziale nel \itindex{mount~point} \textit{mount point} dello stesso si avrà +iniziale nel \itindex{mount~point} \textit{mount point} dello stesso, si avrà comunque un punto di partenza. Inoltre essendo questa \textit{dentry} relativa a quel tipo di filesystem essa farà riferimento ad un \textit{inode} di quel filesystem, e come vedremo questo farà sì che venga eseguita una @@ -458,7 +458,7 @@ opportuno tenere sempre presente che: che contiene riferimenti ad \textit{inode} relativi ad altri filesystem. Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una nuova voce per un file esistente con la funzione \func{link} (vedi - sez.~\ref{sec:file_link}) a file nel filesystem corrente. + sez.~\ref{sec:file_link}), a operare su file nel filesystem corrente. \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto del file non viene spostato fisicamente, viene semplicemente creata una @@ -516,13 +516,13 @@ nativo di diversi filesystem che sono in uso da anni, quello che gli avvicina di più è la famiglia di filesystem evolutasi a partire dal \textit{second extended filesystem}, o \acr{ext2}. Il filesystem \acr{ext2} ha subito un grande sviluppo e diverse evoluzioni, fra cui l'aggiunta del -\textit{journaling} con \acr{ext3}, probabilmente ancora il filesystem più -diffuso, ed una serie di ulteriori miglioramento con il successivo \acr{ext4}, -che sta iniziando a sostituirlo gradualmente. In futuro è previsto che questo -debba essere sostituito da un filesystem completamente diverso, \acr{btrfs}, -che dovrebbe diventare il filesystem standard di Linux, ma questo al momento è -ancora in fase di sviluppo.\footnote{si fa riferimento al momento dell'ultima - revisione di di questo paragrafo, l'inizio del 2012.} +\textit{journaling} con il passaggio ad \acr{ext3}, che probabilmente è ancora +il filesystem più diffuso, ed una serie di ulteriori miglioramenti con il +successivo \acr{ext4}, che sta iniziando a sostituirlo gradualmente. In futuro +è previsto che questo debba essere sostituito da un filesystem completamente +diverso, \acr{btrfs}, che dovrebbe diventare il filesystem standard di Linux, +ma questo al momento è ancora in fase di sviluppo.\footnote{si fa riferimento + al momento dell'ultima revisione di di questo paragrafo, l'inizio del 2012.} Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire dalle prime versioni del kernel e supporta tutte le caratteristiche di un @@ -620,9 +620,9 @@ contenenti un gran numero di file. \label{sec:sys_file_config} Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file -occorre prima rendere disponibile al sistema il filesystem su cui essi sono -memorizzati; l'operazione di attivazione del filesystem è chiamata -\textsl{montaggio}, per far questo in Linux si usa la funzione \funcd{mount}, +occorre rendere disponibile al sistema il filesystem su cui essi sono +memorizzati. L'operazione di attivazione del filesystem è chiamata +\textsl{montaggio} e per far questo in Linux si usa la funzione \funcd{mount}, il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che usa la omonima \textit{system call} e non è portabile.} @@ -725,8 +725,8 @@ forma della lista di parole chiave indicata con l'argomento \param{data}, esistono pure alcune opzioni che si possono applicare in generale, anche se non è detto che tutti i filesystem le supportino, che si specificano tramite l'argomento \param{mountflags}. L'argomento inoltre può essere utilizzato per -modificare il comportamento della funzione, facendole compiere una operazione -diversa (ad esempio un rimontaggio, invece che un montaggio). +modificare il comportamento della funzione \func{mount}, facendole compiere +una operazione diversa (ad esempio un rimontaggio, invece che un montaggio). In Linux \param{mountflags} deve essere un intero a 32 bit; fino ai kernel della serie 2.2.x i 16 più significativi avevano un valore riservato che @@ -748,8 +748,8 @@ identificati dalle costanti riportate nell'elenco seguente: possibile montare una directory di un filesystem in un'altra directory, l'opzione è disponibile a partire dai kernel della serie 2.4. In questo caso verranno presi in considerazione solo gli argomenti \param{source}, che - stavolta indicherà la directory che si vuole montare (e non un file di - dispositivo) e \param{target} che indicherà la directory su cui verrà + stavolta indicherà la directory che si vuole montare e non un file di + dispositivo, e \param{target} che indicherà la directory su cui verrà effettuato il \textit{bind mount}. Gli argomenti \param{filesystemtype} e \param{data} vengono ignorati. @@ -787,20 +787,19 @@ identificati dalle costanti riportate nell'elenco seguente: Fino al kernel 2.6.26 questo flag doveva essere usato da solo, in quanto il \textit{bind mount} continuava ad utilizzare le stesse opzioni del montaggio originale, dal 2.6.26 è stato introdotto il supporto per il cosiddetto - \textit{read-only bind mount} e viene onorata la presenza del flag - \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file sotto - \param{target} sia effettuabile esclusivamente in sola lettura. + \textit{read-only bind mount} e viene onorata la presenza aggiuntiva del + flag \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file + sotto \param{target} sia effettuabile esclusivamente in sola lettura. Il supporto per il \textit{bind mount} consente di superare i limiti presenti per gli \textit{hard link} (di cui parleremo in - sez.~\ref{sec:file_link}) ottenendo un qualcosa di analogo in cui si può - fare riferimento alla porzione dell'albero dei file di un filesystem - presente a partire da una certa directory utilizzando una qualunque altra - directory, anche se questa sta su un filesystem diverso. Si può così fornire - una alternativa all'uso dei link simbolici (di cui parleremo in - sez.~\ref{sec:file_symlink}) che funziona correttamente anche all'intero di - un \textit{chroot} (argomento su cui torneremo in - sez.~\ref{sec:file_chroot}. + sez.~\ref{sec:file_link}) con la possibilità di fare riferimento alla + porzione dell'albero dei file di un filesystem presente a partire da una + certa directory, utilizzando una qualunque altra directory, anche se questa + sta su un filesystem diverso. Si può così fornire una alternativa all'uso + dei link simbolici (di cui parleremo in sez.~\ref{sec:file_symlink}) che + funziona correttamente anche all'intero di un \textit{chroot} (argomento su + cui torneremo in sez.~\ref{sec:file_chroot}). \itindend{bind~mount} \item[\const{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una @@ -808,7 +807,7 @@ identificati dalle costanti riportate nell'elenco seguente: (introdotta a partire dai kernel della serie 2.6). L'opzione si applica a tutte le directory del filesystem, ma su alcuni filesystem è possibile impostarla a livello di singole directory o per i sottorami di una directory - con il comando \cmd{lsattr}.\footnote{questo avviene tramite delle opportune + con il comando \cmd{chattr}.\footnote{questo avviene tramite delle opportune \texttt{ioctl} (vedi sez.~\ref{sec:file_ioctl}).} Questo consente di ridurre al minimo il rischio di perdita dei dati delle @@ -961,7 +960,7 @@ identificati dalle costanti riportate nell'elenco seguente: cambiandone le opzioni di montaggio in maniera atomica. In questo modo si possono modificare le opzioni del filesystem anche se questo è in uso. Gli argomenti \param{source} e \param{target} devono essere gli stessi usati per - il montaggio originale, mentre \param{data} che \param{mountflags} + il montaggio originale, mentre sia \param{data} che \param{mountflags} conterranno le nuove opzioni, \param{filesystemtype} viene ignorato. Qualunque opzione specifica del filesystem indicata con \param{data} può @@ -982,14 +981,16 @@ identificati dalle costanti riportate nell'elenco seguente: point} che si intende marcare, e tutti gli altri argomenti verranno ignorati. - Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount} - effettuati da un \textit{mount point} marcato da essa siano di tipo - \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro - ogni ulteriore operazione di montaggio o smontaggio che avviene su una - directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e - smontaggio cioè vengono ``\textsl{propagate}'' a tutti i \textit{mount - point} della stessa condivisione, e la sezione di albero di file vista al - di sotto di ciascuno di essi sarà sempre identica. + Lo scopo dell'opzione è ottenere che tutti i successivi \itindex{bind~mount} + \textit{bind mount} effettuati da un \textit{mount point} marcato da essa + siano di tipo \textit{shared}, cioè ``\textsl{condividano}'' con l'originale + e fra di loro ogni ulteriore operazione di montaggio o smontaggio che + avviene su una directory al di sotto di uno qualunque di essi. Le operazioni + di montaggio e smontaggio effettuate al di sotto di un qualunque + \textit{mount point} così marcato verranno ``\textsl{propagate}'' a tutti i + \itindex{mount~point} \textit{mount point} della stessa condivisione, e la + sezione di albero di file vista al di sotto di ciascuno di essi sarà sempre + identica. \item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione @@ -1010,7 +1011,7 @@ identificati dalle costanti riportate nell'elenco seguente: effettuati da un \textit{mount point} marcato da essa siano di tipo \textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di montaggio o smontaggio che avviene su una directory al di sotto del - \textit{mount point} originale. Le operazioni di montaggio e smontaggio in + \textit{mount point} originale. Le operazioni di montaggio e smontaggio in questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point} originale (detto anche \textit{master}) verso gli \textit{slave}, mentre essi potranno eseguire al loro interno ulteriori montaggi che non saranno @@ -1045,13 +1046,13 @@ identificati dalle costanti riportate nell'elenco seguente: \param{target} dovrà fare riferimento al \textit{mount point} che si intende marcare, e tutti gli altri argomenti verranno ignorati. - Un \textit{mount point} marcato in questo modo disabilità la capacità di - eseguire dei \itindex{bind~mount} \textit{bind mount}. Si comporta cioè come - allo stesso modo di un \itindex{mount~point} \textit{mount point} ordinario - di tipo \textit{private} con in più la restrizione che nessuna sua - sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere - utilizzata per un come sorgente di un \itindex{bind~mount} \textit{bind - mount}. + Un \textit{mount point} marcato in questo modo disabilita la capacità di + eseguire dei \itindex{bind~mount} \textit{bind mount} del suo contenuto. Si + comporta cioè come allo stesso modo di un \itindex{mount~point} + \textit{mount point} ordinario di tipo \textit{private} con in più la + restrizione che nessuna sua sottodirectory (anche se relativa ad un + ulteriore montaggio) possa essere utilizzata per un come sorgente di un + \itindex{bind~mount} \textit{bind mount}. \end{basedescript} @@ -1181,13 +1182,24 @@ con un errore di \errcode{EAGAIN}, mentre in caso di filesystem occupato si sarebbe ricevuto \errcode{BUSY}. Una volta marcato, se nel frattempo non viene fatto nessun uso del filesystem, ad una successiva chiamata con \const{MNT\_EXPIRE} questo verrà smontato. Questo flag consente di realizzare -un meccanismo che smonti automaticamente i filesystem che restano inutilizzato +un meccanismo che smonti automaticamente i filesystem che restano inutilizzati per un certo periodo di tempo. -% Infine il flag \const{UMOUNT\_NOFOLLOW} impedisce l'uso di un link simbolico -% per \param{target} evitando così che si possano passare ai programmi che -% effettuano lo smontaggio dei filesystem per i quali è previsto la possibilità -% di gestione da parte degli utenti con uno programma \acr{sgid} +Infine il flag \const{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se +questo è un link simbolico (vedi sez.~\ref{sec:file_symlink}). Questa è una +misura di sicurezza introdotta per evitare, per quei filesystem per il quale è +prevista una gestione diretta da parte degli utenti, come quelli basati su +FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più + interessanti applicazioni del VFS che consente, tramite un opportuno modulo, + di implementare le funzioni del \textit{Virtual File System} in user space, + così da rendere possibile agli utenti l'implementazione di un loro filesytem + qualunque (con applicazioni di grande interesse come il filesystem cifrato + \textit{encfs} o il filesystem di rete \textit{sshfs}).} che si possano +passare ai programmi che effettuano lo smontaggio dei filesystem, che in +genere sono privilegiati ma consentono di agire solo sui propri \textit{mount + point}, dei link simbolici che puntano ad altri \textit{mount point}, +ottenendo così la possibilità di smontare qualunque filesystem. + Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD, ma con una struttura diversa.} utili per ottenere in maniera diretta @@ -1212,13 +1224,15 @@ informazioni riguardo al filesystem su cui si trova un certo file, sono \end{funcproto} Queste funzioni permettono di ottenere una serie di informazioni generali -riguardo al filesystem su cui si trova il file specificato con un ; queste vengono -restituite all'indirizzo \param{buf} di una struttura \struct{statfs} definita -come in fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il -filesystem in esame sono impostati a zero. I valori del campo \var{f\_type} -sono definiti per i vari filesystem nei relativi file di header dei sorgenti -del kernel da costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in -genere è il nome del filesystem stesso. +riguardo al filesystem su cui si trova il file specificato con un +\textit{pathname} per \func{statfs} e con un file descriptor (vedi +sez.~\ref{sec:file_fd}) per \func{statfs}. Le informazioni vengono restituite +all'indirizzo \param{buf} di una struttura \struct{statfs} definita come in +fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il filesystem in +esame sono impostati a zero. I valori del campo \var{f\_type} sono definiti +per i vari filesystem nei relativi file di header dei sorgenti del kernel da +costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in genere è il nome +del filesystem stesso. \begin{figure}[!htb] \footnotesize \centering @@ -1235,15 +1249,24 @@ file \conffile{/etc/fstab} ed \conffile{/etc/mtab}, che convenzionalmente sono usati in quasi tutti i sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai filesystem da montare e a quelli correntemente montati. Le funzioni servono a leggere il contenuto di questi file in -opportune strutture \struct{fstab} e \struct{mntent}, e, per -\conffile{/etc/mtab} per inserire e rimuovere le voci presenti nel file. - -In generale si dovrebbero usare queste funzioni (in particolare quelle -relative a \conffile{/etc/mtab}), quando si debba scrivere un programma che -effettua il montaggio di un filesystem; in realtà in questi casi è molto più -semplice invocare direttamente il programma \cmd{mount}, per cui ne -tralasceremo la trattazione, rimandando al manuale delle \acr{glibc} -\cite{glibc} per la documentazione completa. +opportune strutture \struct{fstab} e \struct{mntent}, e, nel caso di +\conffile{/etc/mtab}, per inserire e rimuovere le voci presenti nel file. + +In generale si dovrebbero usare queste funzioni, in particolare quelle +relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che +effettua il montaggio di un filesystem. In realtà in questi casi è molto più +semplice invocare direttamente il programma \cmd{mount}. Inoltre l'uso stesso +di \conffile{/etc/mtab} è considerato una pratica obsoleta, in quanto se non +aggiornato correttamente (cosa che è impossibile se la radice è montata in +sola lettura) il suo contenuto diventa fuorviante. + +Pe questo motivo il suo utilizzo viene deprecato ed in molti casi viene già +oggi sostituito da un link simbolico a \procfile{/proc/mounts}, che contiene +una versione degli stessi contenuti (vale a dire l'elenco dei filesystem +montati) generata direttamente dal kernel, e quindi sempre disponibile e +sempre aggiornata. Per questo motivo tralasceremo la trattazione, di queste +funzioni, rimandando al manuale delle \acr{glibc} \cite{glibc} per la +documentazione completa. % TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C) % TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...) @@ -1255,11 +1278,11 @@ Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like la gestione dei file ha delle caratteristiche specifiche che derivano direttamente dall'architettura del sistema. In questa sezione esamineremo le funzioni usate per la manipolazione di file e directory, per la creazione di -link simbolici e diretti, per la gestione e la lettura delle directory. - -In particolare ci soffermeremo sulle conseguenze che derivano -dall'architettura dei filesystem illustrata nel capitolo precedente per quanto -riguarda il comportamento e gli effetti delle varie funzioni. +link simbolici e diretti, per la gestione e la lettura delle directory. In +particolare ci soffermeremo sulle conseguenze che derivano dalla struttura +generica di un qualunque filesystem illustrata in +sez.~\ref{sec:file_filesystem} per quanto attiene il comportamento e gli +effetti delle varie funzioni. \subsection{Le funzioni \func{link} e \func{unlink}} @@ -1271,9 +1294,9 @@ o i nomi logici del VMS) che permettono di fare riferimento allo stesso file chiamandolo con nomi diversi o accedendovi da directory diverse. Questo è possibile anche in ambiente Unix, dove tali collegamenti sono -usualmente chiamati \textit{link}; ma data l'architettura del sistema riguardo -la gestione dei file ci sono due metodi sostanzialmente diversi per fare -questa operazione. +usualmente chiamati ``\textit{link}''; ma data l'architettura del sistema +riguardo la gestione dei file ci sono due metodi sostanzialmente diversi per +fare questa operazione. Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un file su disco avviene passando attraverso il suo \itindex{inode} @@ -1283,18 +1306,19 @@ trova nella voce di una directory è solo un'etichetta, mantenuta all'interno della directory, che viene associata ad un puntatore che fa riferimento al suddetto \textit{inode}. -Questo significa che, fintanto che si resta sullo stesso filesystem, la -realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi +Questo significa che fintanto che si resta sullo stesso filesystem la +realizzazione di un link è immediata ed uno stesso file può avere tanti nomi diversi, dati da altrettante associazioni diverse allo stesso \itindex{inode} -\textit{inode} effettuate tramite ``etichette'' diverse in directory -diverse. Si noti anche che nessuno di questi nomi viene ad assumere una -particolare preferenza o originalità rispetto agli altri, in quanto tutti -fanno comunque riferimento allo stesso \itindex{inode} \textit{inode}. +\textit{inode} effettuate tramite ``etichette'' diverse (voci, nella +nomenclatura di sez.~\ref{sec:file_filesystem}) in directory diverse. Si noti +anche che nessuno di questi nomi viene ad assumere una particolare preferenza +o originalità rispetto agli altri, in quanto tutti fanno comunque riferimento +allo stesso \itindex{inode} \textit{inode}. Per aggiungere ad una directory una voce che faccia riferimento ad un \itindex{inode} \textit{inode} già esistente si utilizza la funzione -\funcd{link}; si suole chiamare questo tipo di associazione un collegamento -diretto, o \textit{hard link}. Il prototipo della funzione è il seguente: +\funcd{link}, e si suole chiamare questo tipo di associazione un collegamento +diretto, o \textit{hard link}. Il prototipo della funzione è il seguente: \begin{funcproto}{ \fhead{unistd.h} @@ -1304,19 +1328,19 @@ diretto, o \textit{hard link}. Il prototipo della funzione è il seguente: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno - riferimento ad un filesystem montato sullo stesso \itindex{mount~point} - \textit{mount point}. - \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e - \param{newpath} non supporta i link diretti o è una directory. \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath} esiste già. \item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi sez.~\ref{sec:sys_limits}). - \end{errlist} ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, - \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, \errval{EROFS}, - \errval{ELOOP}, \errval{ENOSPC}, \errval{EIO} nel loro significato + \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e + \param{newpath} non supporta i link diretti o è una directory. + \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno + riferimento ad un filesystem montato sullo stesso \itindex{mount~point} + \textit{mount point}. + \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO}, + \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, + \errval{ENOSPC}, \errval{ENOTDIR}, \errval{EROFS} nel loro significato generico.} \end{funcproto} @@ -1327,12 +1351,12 @@ nuovo collegamento diretto non copia il contenuto del file, ma si limita a creare una voce nella directory specificata da \param{newpath} e ad aumentare di uno il numero di riferimenti al file (riportato nel campo \var{st\_nlink} della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat}) aggiungendo il -nuovo nome ai precedenti. Si noti che uno stesso file può essere così chiamato +nuovo nome ai precedenti. In questo modo lo stesso file può essere chiamato con vari nomi in diverse directory. Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un collegamento diretto è possibile solo se entrambi i \textit{pathname} sono -nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti +nello stesso filesystem. Inoltre il filesystem deve supportare i collegamenti diretti (il meccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di Windows). In realtà la funzione ha un ulteriore requisito, e cioè che non solo che i due file siano sullo stesso filesystem, ma anche che @@ -1346,9 +1370,9 @@ filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo l'amministratore è in grado di creare un collegamento diretto ad un'altra directory: questo viene fatto perché con una tale operazione è possibile creare dei \textit{loop} nel filesystem (vedi l'esempio mostrato in -sez.~\ref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi -non sono in grado di gestire e la cui rimozione diventerebbe estremamente -complicata (in genere per questo tipo di errori occorre far girare il +sez.~\ref{sec:file_symlink}, dove riprenderemo il discorso) che molti +programmi non sono in grado di gestire e la cui rimozione diventerebbe +piuttosto complicata (in genere per questo tipo di errori occorre eseguire il programma \cmd{fsck} per riparare il filesystem). Data la pericolosità di questa operazione e la disponibilità dei link @@ -1360,22 +1384,24 @@ disabilitata, e al tentativo di creare un link diretto ad una directory la funzione \func{link} restituisce l'errore \errcode{EPERM}. Un ulteriore comportamento peculiare di Linux è quello in cui si crea un -\textit{hard link} ad un link simbolico. In questo caso lo standard POSIX -prevederebbe che quest'ultimo venga risolto e che il collegamento sia -effettuato rispetto al file cui esso punta, e che venga riportato un errore -qualora questo non esista o non sia un file. Questo era anche il comportamento -iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la - precisione il comportamento era quello previsto dallo standard POSIX fino al - kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche - durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento - attuale fino ad oggi (per riferimento si veda +\textit{hard link} ad un link simbolico. In questo caso lo standard +POSIX.1-2001 prevederebbe che quest'ultimo venga risolto e che il collegamento +sia effettuato rispetto al file cui esso punta, e che venga riportato un +errore qualora questo non esista o non sia un file. Questo era anche il +comportamento iniziale di Linux ma a partire dai kernel della serie +2.0.x\footnote{per la precisione il comportamento era quello previsto dallo + standard POSIX fino al kernel di sviluppo 1.3.56, ed è stato temporaneamente + ripristinato anche durante lo sviluppo della serie 2.1.x, per poi tornare al + comportamento attuale fino ad oggi (per riferimento si veda \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento che non segue più lo standard per cui l'\textit{hard link} viene creato -rispetto al link simbolico, e non al file cui questo punta. +rispetto al link simbolico, e non al file cui questo punta. La revisione +POSIX.1-2008 lascia invece il comportamento dipendente dall'implementazione, +cosa che rende Linux aderente allo standard. -La ragione di questa differenza rispetto allo standard, presente anche in -altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare -riferimento anche ad un file non esistente o a una directory, per i quali +La ragione di questa differenza rispetto al vecchio standard, presente anche +in altri sistemi unix-like, sono dovute al fatto che un link simbolico può +fare riferimento anche ad un file non esistente o a una directory, per i quali l'\textit{hard link} non può essere creato, per cui la scelta di seguire il link simbolico è stata ritenuta una scelta scorretta nella progettazione dell'interfaccia. Infatti se non ci fosse il comportamento adottato da Linux @@ -1385,10 +1411,10 @@ destinazione. Invece evitando di seguire lo standard l'operazione diventa possibile, ed anche il comportamento della funzione risulta molto più comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard link} rispetto alla destinazione di un link simbolico è sempre possibile -farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori - standard possa causare problemi, come nell'esempio descritto nell'articolo - citato nella nota precedente, a programmi che non si aspettano questa - differenza rispetto allo standard POSIX.} +farlo direttamente.\footnote{ciò non toglie che questo comportamento possa + causare problemi, come nell'esempio descritto nell'articolo citato nella + nota precedente, a programmi che non si aspettano questa differenza rispetto + allo standard POSIX.} La rimozione di un file (o più precisamente della voce che lo referenzia all'interno di una directory) si effettua con la funzione \funcd{unlink}; il -- 2.30.2