\errval{ENOSPC}, \errval{EIO}.}
\end{prototype}
-La funzione crea sul \index{\textit{pathname}}\textit{pathname}
-\param{newpath} un collegamento diretto al file indicato da \param{oldpath}.
-Per quanto detto la creazione di un 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 con vari nomi in diverse directory.
+La funzione crea sul \itindex{pathname}\textit{pathname} \param{newpath} un
+collegamento diretto al file indicato da \param{oldpath}. Per quanto detto la
+creazione di un 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 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
-\index{\textit{pathname}}\textit{pathname} sono nello stesso filesystem;
-inoltre il filesystem deve supportare i collegamenti diretti (il meccanismo
-non è disponibile ad esempio con il filesystem \acr{vfat} di Windows).
+\itindex{pathname}\textit{pathname} sono nello stesso filesystem; inoltre il
+filesystem deve supportare i collegamenti diretti (il meccanismo non è
+disponibile ad esempio con il filesystem \acr{vfat} di Windows).
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
\param{oldpath} o più in generale si è cercato di creare una directory come
sotto-directory di se stessa.
\item[\errcode{ENOTDIR}] Uno dei componenti dei
- \index{\textit{pathname}}\textit{pathname} non è una directory o
- \param{oldpath} è una directory e \param{newpath} esiste e non è una
- directory.
+ \itindex{pathname}\textit{pathname} non è una directory o \param{oldpath}
+ è una directory e \param{newpath} esiste e non è una directory.
\end{errlist}
ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
\errval{ENOENT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP} e
\file{/boot/boot/boot} e così via.
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
-un \index{\textit{pathname}}\textit{pathname} possano essere seguiti un numero
+un \itindex{pathname}\textit{pathname} possano essere seguiti un numero
limitato di link simbolici, il cui valore limite è specificato dalla costante
\const{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
errore ed \var{errno} viene impostata al valore \errcode{ELOOP}.
La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
standard (\file{.} e \file{..}), con il nome indicato dall'argomento
\param{dirname}. Il nome può essere indicato sia come
-\index{\textit{pathname}}\textit{pathname} assoluto che relativo.
+\itindex{pathname}\textit{pathname} assoluto che relativo.
I permessi di accesso alla directory (vedi sez.~\ref{sec:file_access_control})
sono specificati da \param{mode}, i cui possibili valori sono riportati in
La funzione cancella la directory \param{dirname}, che deve essere vuota (la
directory deve cioè contenere soltanto le due voci standard \file{.} e
\file{..}). Il nome può essere indicato con il
-\index{\textit{pathname}}\textit{pathname} assoluto o relativo.
+\itindex{pathname}\textit{pathname} assoluto o relativo.
La modalità con cui avviene la cancellazione è analoga a quella di
\func{unlink}: fintanto che il numero di link all'inode\index{inode} della
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
- \headdecl{fnctl.h}
+ \headdecl{fcntl.h}
\headdecl{unistd.h}
\funcdecl{int mknod(const char *pathname, mode\_t mode, dev\_t dev)}
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EPERM}] Non si hanno privilegi sufficienti a creare l'inode, o
- il filesystem su cui si è cercato di creare \func{pathname} non supporta
+ il filesystem su cui si è cercato di creare \param{pathname} non supporta
l'operazione.
\item[\errcode{EINVAL}] Il valore di \param{mode} non indica un file, una
fifo o un dispositivo.
\end{functions}
La funzione restituisce in \param{result} (come
-\index{\textit{value~result~argument}}\textit{value result argument})
-l'indirizzo dove sono stati salvati i dati, che di norma corrisponde a quello
-della struttura precedentemente allocata e specificata dall'argomento
-\param{entry} (anche se non è assicurato che la funzione usi lo spazio fornito
-dall'utente).
+\itindex{value~result~argument}\textit{value result argument}) l'indirizzo
+dove sono stati salvati i dati, che di norma corrisponde a quello della
+struttura precedentemente allocata e specificata dall'argomento \param{entry}
+(anche se non è assicurato che la funzione usi lo spazio fornito dall'utente).
I vari campi di \struct{dirent} contengono le informazioni relative alle voci
presenti nella directory; sia BSD che SVr4\footnote{POSIX prevede invece solo
directory, mentre il campo \var{d\_reclen} la lunghezza totale della voce
letta. Con questi due campi diventa possibile, determinando la posizione delle
varie voci, spostarsi all'interno dello stream usando la funzione
-\func{seekdir},\footnote{sia questa funzione che \func{telldir}, sono
+\funcd{seekdir},\footnote{sia questa funzione che \func{telldir}, sono
estensioni prese da BSD, non previste dallo standard POSIX.} il cui
prototipo è:
\begin{prototype}{dirent.h}{void seekdir(DIR *dir, off\_t offset)}
La funzione non ritorna nulla e non segnala errori, è però necessario che il
valore dell'argomento \param{offset} sia valido per lo stream \param{dir};
esso pertanto deve essere stato ottenuto o dal valore di \var{d\_off} di
-\struct{dirent} o dal valore restituito dalla funzione \func{telldir}, che
+\struct{dirent} o dal valore restituito dalla funzione \funcd{telldir}, che
legge la posizione corrente; il prototipo di quest'ultima è:
\begin{prototype}{dirent.h}{off\_t telldir(DIR *dir)}
Ritorna la posizione corrente in un \textit{directory stream}.
a partire dalla versione 2.1, effettuano anche l'ordinamento alfabetico
tenendo conto delle varie localizzazioni, usando \func{strcoll} al posto di
\func{strcmp}.} anche \func{versionsort}, che ordina i nomi tenendo conto
-del numero di versione (cioè qualcosa per cui \file{file10} viene comunque
-dopo \func{file4}.)
+del numero di versione (cioè qualcosa per cui \texttt{file10} viene comunque
+dopo \texttt{file4}.)
Un semplice esempio dell'uso di queste funzioni è riportato in
fig.~\ref{fig:file_my_ls}, dove si è riportata la sezione principale di un
\subsection{La directory di lavoro}
\label{sec:file_work_dir}
+\itindbeg{pathname}
+
A ciascun processo è associata una directory nel filesystem che è chiamata
\textsl{directory corrente} o \textsl{directory di lavoro} (in inglese
\textit{current working directory}) che è quella a cui si fa riferimento
-quando un \index{\textit{pathname}}\textit{pathname} è espresso in forma
+quando un \itindsub{pathname}{relativo}\textit{pathname} è espresso in forma
relativa, dove il ``\textsl{relativa}'' fa riferimento appunto a questa
directory.
directory corrente di qualunque comando da essa lanciato.
In genere il kernel tiene traccia per ciascun processo dell'inode\index{inode}
-della directory di lavoro, per ottenere il
-\index{\textit{pathname}}\textit{pathname} occorre usare una apposita funzione
-di libreria, \funcd{getcwd}, il cui prototipo è:
+della directory di lavoro, per ottenere il \textit{pathname}
+occorre usare una apposita funzione di libreria, \funcd{getcwd}, il cui
+prototipo è:
\begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}
Legge il \textit{pathname} della directory di lavoro corrente.
\end{errlist}}
\end{prototype}
-La funzione restituisce il \index{\textit{pathname}}\textit{pathname} completo
-della directory di lavoro nella stringa puntata da \param{buffer}, che deve
-essere precedentemente allocata, per una dimensione massima di \param{size}.
-Il buffer deve essere sufficientemente lungo da poter contenere il
+La funzione restituisce il \textit{pathname} completo della directory di
+lavoro nella stringa puntata da \param{buffer}, che deve essere
+precedentemente allocata, per una dimensione massima di \param{size}. Il
+buffer deve essere sufficientemente lungo da poter contenere il
\textit{pathname} completo più lo zero di terminazione della stringa. Qualora
esso ecceda le dimensioni specificate con \param{size} la funzione restituisce
un errore.
\param{buffer},\footnote{questa è un'estensione allo standard POSIX.1,
supportata da Linux.} nel qual caso la stringa sarà allocata automaticamente
per una dimensione pari a \param{size} qualora questa sia diversa da zero, o
-della lunghezza esatta del \index{\textit{pathname}}\textit{pathname}
-altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una
-volta cessato il suo utilizzo.
+della lunghezza esatta del \textit{pathname} altrimenti. In questo caso ci si
+deve ricordare di disallocare la stringa una volta cessato il suo utilizzo.
Di questa funzione esiste una versione \code{char *getwd(char *buffer)} fatta
per compatibilità all'indietro con BSD, che non consente di specificare la
dimensione del buffer; esso deve essere allocato in precedenza ed avere una
dimensione superiore a \const{PATH\_MAX} (di solito 256 byte, vedi
sez.~\ref{sec:sys_limits}); il problema è che in Linux non esiste una
-dimensione superiore per un \index{\textit{pathname}}\textit{pathname}, per
-cui non è detto che il buffer sia sufficiente a contenere il nome del file, e
-questa è la ragione principale per cui questa funzione è deprecata.
+dimensione superiore per un \textit{pathname}, per cui non è detto che il
+buffer sia sufficiente a contenere il nome del file, e questa è la ragione
+principale per cui questa funzione è deprecata.
Una seconda funzione simile è \code{char *get\_current\_dir\_name(void)} che è
sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la sola
differenza che essa ritorna il valore della variabile di ambiente \val{PWD},
che essendo costruita dalla shell può contenere un \textit{pathname}
comprendente anche dei link simbolici. Usando \func{getcwd} infatti, essendo
-il \index{\textit{pathname}}\textit{pathname} ricavato risalendo all'indietro
-l'albero della directory, si perderebbe traccia di ogni passaggio attraverso
-eventuali link simbolici.
+il \textit{pathname} ricavato risalendo all'indietro l'albero della directory,
+si perderebbe traccia di ogni passaggio attraverso eventuali link simbolici.
Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
(equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
quale si hanno i permessi di accesso.
Dato che anche le directory sono file, è possibile riferirsi ad esse anche
-tramite il file descriptor, e non solo tramite il
-\index{\textit{pathname}}\textit{pathname}, per fare questo si usa
-\funcd{fchdir}, il cui prototipo è:
+tramite il file descriptor, e non solo tramite il \textit{pathname}, per fare
+questo si usa \funcd{fchdir}, il cui prototipo è:
\begin{prototype}{unistd.h}{int fchdir(int fd)}
Identica a \func{chdir}, ma usa il file descriptor \param{fd} invece del
\textit{pathname}.
quello in cui il processo non ha il permesso di accesso alla directory
specificata da \param{fd}.
+\itindend{pathname}
+
\subsection{I file temporanei}
prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
creare il file dopo aver controllato che questo non esista, nel momento fra il
controllo e la creazione si ha giusto lo spazio per una possibile \textit{race
- condition}\index{\textit{race~condition}} (si ricordi quanto visto in
+ condition}\itindex{race~condition} (si ricordi quanto visto in
sez.~\ref{sec:proc_race_cond}).
Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei,
esistente.
Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
-POSIX definisce la funzione \funcd{tempfile}, il cui prototipo è:
+POSIX definisce la funzione \funcd{tmpfile}, il cui prototipo è:
\begin{prototype}{stdio.h}{FILE *tmpfile (void)}
Restituisce un file temporaneo aperto in lettura/scrittura.
standard non specifica in quale directory verrà aperto il file, ma le
\acr{glibc} prima tentano con \const{P\_tmpdir} e poi con \file{/tmp}. Questa
funzione è rientrante e non soffre di problemi di \textit{race
- condition}\index{\textit{race~condition}}.
+ condition}\itindex{race~condition}.
Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
\end{prototype}
\noindent dato che \param{template} deve poter essere modificata dalla
funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
-alle possibili \textit{race condition}\index{\textit{race~condition}} date per
+alle possibili \textit{race condition}\itindex{race~condition} date per
\func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid}
del processo più una lettera, il che mette a disposizione solo 26 possibilità
\noindent la directory è creata con permessi \code{0700} (al solito si veda
cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la creazione
della directory è sempre esclusiva i precedenti problemi di \textit{race
- condition}\index{\textit{race~condition}} non si pongono.
+ condition}\itindex{race~condition} non si pongono.
\section{La manipolazione delle caratteristiche dei files}
Il campo \var{st\_size} contiene la dimensione del file in byte (se si tratta
di un file regolare, nel caso di un link simbolico la dimensione è quella del
-\index{\textit{pathname}}\textit{pathname} che contiene, per le fifo è sempre
-nullo).
+\itindex{pathname}\textit{pathname} che contiene, per le fifo è sempre nullo).
Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
\begin{errlist}
\item[\errcode{EACCES}] il file non ha permesso di scrittura o non si ha il
permesso di esecuzione una delle directory del
- \index{\textit{pathname}}\textit{pathname}.
+ \itindex{pathname}\textit{pathname}.
\item[\errcode{ETXTBSY}] Il file è un programma in esecuzione.
\end{errlist}
ed anche \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\end{prototype}
La funzione prende come argomento \param{times} una struttura
-\struct{utimebuf}, la cui definizione è riportata in
+\struct{utimbuf}, la cui definizione è riportata in
fig.~\ref{fig:struct_utimebuf}, con la quale si possono specificare i nuovi
valori che si vogliono impostare per tempi.
\centering
\includegraphics[width=6cm]{img/fileperm}
\caption{Lo schema dei bit utilizzati per specificare i permessi di un file
- contenuti nel campo \var{st\_mode} di \struct{fstat}.}
+ contenuti nel campo \var{st\_mode} di \struct{stat}.}
\label{fig:file_perm_bit}
\end{figure}
avanti.
La prima regola è che per poter accedere ad un file attraverso il suo
-\textit{pathname} occorre il permesso di esecuzione in ciascuna delle
-directory che compongono il \textit{pathname}; lo stesso vale per aprire un
-file nella directory corrente (per la quale appunto serve il diritto di
-esecuzione).
+\itindex{pathname}\textit{pathname} occorre il permesso di esecuzione in
+ciascuna delle directory che compongono il \textit{pathname}; lo stesso vale
+per aprire un file nella directory corrente (per la quale appunto serve il
+diritto di esecuzione).
Per una directory infatti il permesso di esecuzione significa che essa può
-essere attraversata nella risoluzione del
-\index{\textit{pathname}}\textit{pathname}, ed è distinto dal permesso di
-lettura che invece implica che si può leggere il contenuto della directory.
+essere attraversata nella risoluzione del \itindex{pathname}\textit{pathname},
+ed è distinto dal permesso di lettura che invece implica che si può leggere il
+contenuto della directory.
Questo significa che se si ha il permesso di esecuzione senza permesso di
lettura si potrà lo stesso aprire un file in una directory (se si hanno i
sez.~\ref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la
prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della
macchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file
-continuo indicizzato direttamente in questo modo si poteva risparmiare in
-tempo di caricamento rispetto alla ricerca del file su disco. Lo
-\textsl{sticky bit} è indicato usando la lettera \cmd{t} al posto della
-\cmd{x} nei permessi per gli altri.
+continuo o una partizione indicizzata direttamente si poteva risparmiare in
+tempo di caricamento rispetto alla ricerca attraverso la struttura del
+filesystem. Lo \textsl{sticky bit} è indicato usando la lettera \cmd{t} al
+posto della \cmd{x} nei permessi per gli altri.
Ovviamente per evitare che gli utenti potessero intasare la swap solo
l'amministratore era in grado di impostare questo bit, che venne chiamato
di norma corrispondente alla radice dell'albero di file e directory come visto
dal kernel (ed illustrato in sez.~\ref{sec:file_organization}), ha per il
processo il significato specifico di directory rispetto alla quale vengono
-risolti i \index{\textit{pathname}!assoluto}\textit{pathname}
+risolti i \itindsub{pathname}{assoluto}\textit{pathname}
assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
\textit{pathname}, il kernel usa sempre questa directory come punto di
partenza.} Il fatto che questo valore sia specificato per ogni processo apre
allora la possibilità di modificare le modalità di risoluzione dei
\textit{pathname} assoluti da parte di un processo cambiando questa directory,
-così come si fa coi \index{\textit{pathname}!relativo}\textit{pathname}
-relativi cambiando la directory di lavoro.
+così come si fa coi \itindsub{pathname}{relativo}\textit{pathname} relativi
+cambiando la directory di lavoro.
Normalmente la directory radice di un processo coincide anche con la radice
del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal
padre da ogni processo figlio, in generale i processi risolvono i
-\index{\textit{pathname}!assoluto}\textit{pathname} assoluti a partire sempre
-dalla stessa directory, che corrisponde alla \file{/} del sistema.
+\itindsub{pathname}{assoluto}\textit{pathname} assoluti a partire sempre dalla
+stessa directory, che corrisponde alla \file{/} del sistema.
In certe situazioni però, per motivi di sicurezza, è utile poter impedire che
un processo possa accedere a tutto il filesystem; per far questo si può
\end{prototype}
\noindent in questo modo la directory radice del processo diventerà
\param{path} (che ovviamente deve esistere) ed ogni
-\index{\textit{pathname}!assoluto}\textit{pathname} assoluto usato dalle
-funzioni chiamate nel processo sarà risolto a partire da essa, rendendo
-impossibile accedere alla parte di albero sovrastante. Si ha così quella che
-viene chiamata una \textit{chroot jail}, in quanto il processo non può più
-accedere a file al di fuori della sezione di albero in cui è stato
+\itindsub{pathname}{assoluto}\textit{pathname} assoluto usato dalle funzioni
+chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
+accedere alla parte di albero sovrastante. Si ha così quella che viene
+chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
+a file al di fuori della sezione di albero in cui è stato
\textsl{imprigionato}.
Solo un processo con i privilegi di amministratore può usare questa funzione,
si cedono i privilegi di root. Infatti se per un qualche motivo il processo
resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
comunque accedere a tutto il resto del filesystem usando
-\index{\textit{pathname}!relativo}\textit{pathname} relativi, i quali,
-partendo dalla directory di lavoro che è fuori della \textit{chroot jail},
-potranno (con l'uso di \texttt{..}) risalire fino alla radice effettiva del
-filesystem.
+\itindsub{pathname}{relativo}\textit{pathname} relativi, i quali, partendo
+dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
+(con l'uso di \texttt{..}) risalire fino alla radice effettiva del filesystem.
Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si