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
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
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
\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.}
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
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.
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
(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
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ò
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
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
\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}
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
\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
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 ...)
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}}
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}
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}
{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}
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
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
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
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
projects / gapil.git / blobdiff