Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
-identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}). Questi valori
+identificatori di utenti e gruppi (\acr{uid} e \acr{gid}). Questi valori
sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
della struttura \var{stat} (si veda \secref{sec:file_stat}). Ad ogni file
viene inoltre associato un insieme di permessi che sono divisi in tre classi,
usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
esecuzione (indicati nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e
\cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti
-gli altri. I restanti tre bit (\textsl{suid}, \textsl{sgid}, e
+gli altri. I restanti tre bit (\acr{suid}, \acr{sgid}, e
\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e
\secref{sec:file_sticky}).
\footnotesize
\begin{tabular}[c]{|c|l|}
\hline
- \var{st\_mode} bit & Significato \\
+ \textbf{\var{st\_mode}} bit & \textbf{Significato} \\
\hline
\hline
\macro{S\_IRUSR} & \textit{user-read}, l'utente può leggere \\
la directory).
Avere il permesso di lettura per un file consente di aprirlo con le opzioni di
-sola lettura (\macro{O\_RDONLY}) o di lettura-scrittura (\macro{O\_RDWR}) e
+sola lettura (\macro{O\_RDONLY}) o di lettura/scrittura (\macro{O\_RDWR}) e
leggerne il contenuto. Avere il permesso di scrittura consente di aprire un
-file in sola scrittura (\macro{O\_WRONLY}) o lettura-scrittura
+file in sola scrittura (\macro{O\_WRONLY}) o lettura/scrittura
(\macro{O\_RDWR}) e modificarne il contenuto, lo stesso permesso è necessario
per poter troncare il file con l'opzione \macro{O\_TRUNC}.
Per una spiegazione dettagliata degli identificatori associati ai processi si
veda \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in
\secref{sec:file_suid_sgid}, l'\textit{effective user id} e
-l'\textit{effective group id} corrispondono a uid e gid dell'utente che ha
-lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei
-gruppi cui l'utente appartiene.
-
-% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
-% confrontandoli con quelli del file e se l'operazione richiesta è compatibile
-% con i permessi associati al file essa viene eseguita, altrimenti viene
-% bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
-% viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale
-% a
-% pertanto accesso senza restrizione a qualunque file del sistema.
-
-% In realtà il procedimento è più complesso di quanto descritto in maniera
-% elementare qui; inoltre ad un processo sono associati diversi identificatori,
-% torneremo su questo in maggiori dettagli in seguito in
-% \secref{sec:proc_perms}.
+l'\textit{effective group id} corrispondono a \acr{uid} e \acr{gid}
+dell'utente che ha lanciato il processo, mentre i \textit{supplementary group
+ id} sono quelli dei gruppi cui l'utente appartiene.
I passi attraverso i quali viene stabilito se il processo possiede il diritto
di accesso sono i seguenti:
\item altrimenti l'accesso è negato
\end{itemize}
\item Se l'\textit{effective group id} del processo o uno dei
- \textit{supplementary group id} dei processi corrispondono al gid del file
- allora:
+ \textit{supplementary group id} dei processi corrispondono al \acr{gid} del
+ file allora:
\begin{itemize}
\item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
consentito,
\item altrimenti l'accesso è negato
\end{itemize}
\item se il bit dei permessi d'accesso per tutti gli altri è settato,
- l'accesso è consentito, altrimenti l'accesso è negato.
+ l'accesso è consentito, altrimenti l'accesso è negato.
\end{itemize}
Si tenga presente che questi passi vengono eseguiti esattamente in
tutti gli altri non vengono controllati.
-\subsection{I bit \textsl{suid} e \textsl{sgid}}
+\subsection{I bit \acr{suid} e \acr{sgid}}
\label{sec:file_suid_sgid}
Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del
campo \var{st\_mode} usati per il controllo di accesso oltre ai bit dei
permessi veri e propri, ci sono altri tre bit che vengono usati per indicare
alcune proprietà speciali dei file. Due di questi sono i bit detti
-\textsl{suid} (o \textit{set-user-ID bit}) e \textsl{sgid} (o
-\textit{set-group-ID bit}) che sono identificati dalle constanti
+\acr{suid} (o \textit{set-user-ID bit}) e \acr{sgid} (o
+\textit{set-group-ID bit}) che sono identificati dalle costanti
\macro{S\_ISUID} e \macro{S\_ISGID}.
Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
-programma il comportamendo normale del kernel è quello di settare
+programma il comportamento normale del kernel è quello di settare
l'\textit{effective user id} e l'\textit{effective group id} del nuovo
-processo all'uid e al gid del processo corrente, che normalmente corrispondono
-dell'utente con cui si è entrati nel sistema.
+processo all'\acr{uid} e al \acr{gid} del processo corrente, che normalmente
+corrispondono dell'utente con cui si è entrati nel sistema.
Se però il file del programma\footnote{per motivi di sicurezza il kernel
ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili} (che
veda \secref{sec:file_ownership} per una spiegazione dettagliata al
proposito).
-Infine Linux utilizza il bit \textsl{sgid} per una ulteriore estensione
-mutuata da SVR4. Il caso in cui il file abbia il bit \textsl{sgid} settato ma
+Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione
+mutuata da SVR4. Il caso in cui il file abbia il bit \acr{sgid} settato ma
non il corrispondente bit di esecuzione viene utilizzato per attivare per
quel file il \textit{mandatory locking} (argomento che affronteremo nei
dettagli in \secref{sec:xxx_mandatory_lock}).
L'effetto di questo bit era che il segmento di testo del programma (si veda
\secref{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
-mecchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file
+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
in questo modo chiunque può leggere, scrivere ed eseguire i file temporanei
ivi memorizzati, sia crearne di nuovi, ma solo l'utente che ha creato un file
nella directory potrà cancellarlo o rinominarlo, così si può evitare che un
-utente possa, più o meno consapevolemnte, cancellare i file degli altri.
+utente possa, più o meno consapevolmente, cancellare i file degli altri.
\subsection{La titolarità di nuovi file e directory}
descritto in \secref{sec:file_dir_creat_rem}).
Lo standard POSIX prescrive che l'uid del nuovo file corrisponda
-all'\textit{effective user id} del processo che lo crea; per il gid invece
-prevede due diverse possibilità:
+all'\textit{effective user id} del processo che lo crea; per il \acr{gid}
+invece prevede due diverse possibilità:
\begin{itemize}
-\item il gid del file corrisponde all'\textit{effective group id} del processo.
-\item il gid del file corrisponde al gid della directory in cui esso è creato.
+\item il \acr{gid} del file corrisponde all'\textit{effective group id} del
+ processo.
+\item il \acr{gid} del file corrisponde al gid della directory in cui esso è
+ creato.
\end{itemize}
in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
semantica BSD. Linux invece segue quella che viene chiamata semantica SVR4; di
-norma cioè il nuovo file viene creato, seguendo la prima opzione, con il gid
-del processo, se però la directory in cui viene creato il file ha il bit
-\textsl{sgid} settato allora viene usata la seconda opzione..
+norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
+\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+bit \acr{sgid} settato allora viene usata la seconda opzione..
-Usare la semantica BSD ha il vantaggio che il gid viene sempre automaticamente
-propagato, restando coerente a quello della directory di partenza, in tutte le
-sottodirectory. La semantica SVR4 offre una maggiore possibilità di scelta, ma
-per ottenere lo stesso risultato necessita che per le nuove directory venga
-anche propagato anche il bit sgid. Questo è comunque il comportamento di
-default di \func{mkdir}, ed é in questo modo ad esempio che Debian assicura
-che le sottodirectory create nelle home di un utente restino sempre con il gid
-del gruppo primario dello stesso.
+Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+automaticamente propagato, restando coerente a quello della directory di
+partenza, in tutte le sottodirectory. La semantica SVR4 offre una maggiore
+possibilità di scelta, ma per ottenere lo stesso risultato necessita che per
+le nuove directory venga anche propagato anche il bit \acr{sgid}. Questo è
+comunque il comportamento di default di \func{mkdir}, ed é in questo modo ad
+esempio che Debian assicura che le sottodirectory create nelle home di un
+utente restino sempre con il \acr{gid} del gruppo primario dello stesso.
\subsection{La funzione \texttt{access}}
\macro{EIO}.
\end{prototype}
+
I valori possibili per il parametro \var{mode} sono esprimibili come
combinazione delle costanti numeriche riportate in \ntab\ (attraverso un OR
binario). I primi tre valori implicano anche la verifica dell'esistenza del
-file, se si vuole verificare solo quest'ultimaa si può usare \macro{F\_OK}, o
+file, se si vuole verificare solo quest'ultima si può usare \macro{F\_OK}, o
anche direttamente \func{stat}. In caso \var{pathname} si riferisca ad un link
simbolico il controllo è fatto sul file a cui esso fa riferimento.
\begin{table}[htb]
\centering
+ \footnotesize
\begin{tabular}{|c|l|}
\hline
- \var{mode} & Significato \\
+ \textbf{\var{mode}} & \textbf{Significato} \\
\hline
\hline
\macro{R\_OK} & verifica il permesso di lettura \\
\begin{table}[!htb]
\centering
+ \footnotesize
\begin{tabular}[c]{|c|c|l|}
\hline
- \var{mode} & Valore & Significato \\
-
+ \textbf{\var{mode}} & \textbf{Valore} & \textbf{Significato} \\
\hline
\hline
\macro{S\_ISUID} & 04000 & set user ID \\
\item per via della semantica SVR4 nella creazione dei nuovi file, si può
avere il caso in cui il file creato da un processo è assegnato a un gruppo
per il quale il processo non ha privilegi. Per evitare che si possa
- assegnare il bit \textsl{sgid} ad un file appartenente a un gruppo per cui
+ assegnare il bit \acr{sgid} ad un file appartenente a un gruppo per cui
non si hanno diritti, questo viene automaticamente cancellato (senza
notifica di errore) da \var{mode} qualora il gruppo del file non corrisponda
a quelli associati al processo (la cosa non avviene quando
in link simbolico si deve usare la funzione \func{lchown}\footnote{fino alla
versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
allora questo comportamento è stato assegnato alla funzione \func{lchown},
- introdotta per l'occazione, ed è stata creata una nuova system call per
+ introdotta per l'occasione, ed è stata creata una nuova system call per
\func{chown} che seguisse i link simbolici}. La funzione \func{fchown} opera
-su un file aperto, essa è mututata da BSD, ma non è nello standard POSIX.
+su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
valore per \var{owner} e \var{group} i valori restano immutati.
Quando queste funzioni sono chiamate con successo da un processo senza i
-privilegi di root entrambi i bit \textsl{suid} e \textsl{sgid} vengono
-cancellati. Questo non avviene per il bit \textsl{sgid} nel caso in cui esso
+privilegi di root entrambi i bit \acr{suid} e \acr{sgid} vengono
+cancellati. Questo non avviene per il bit \acr{sgid} nel caso in cui esso
sia usato (in assenza del corrispondente permesso di esecuzione) per indicare
che per il file è attivo il \textit{mandatory locking}.
\footnotesize
\begin{tabular}[c]{|l|l|}
\hline
- Macro & Tipo del file \\
+ \textbf{Macro} & \textbf{Tipo del file} \\
\hline
\hline
\macro{S\_ISREG(m)} & file regolare \\
\macro{S\_ISDIR(m)} & directory \\
- \macro{S\_ISCHR(m)} & device a caraetteri \\
+ \macro{S\_ISCHR(m)} & device a caratteri \\
\macro{S\_ISBLK(m)} & device a blocchi\\
\macro{S\_ISFIFO(m)} & fifo \\
\macro{S\_ISLNK(m)} & link simbolico \\
\footnotesize
\begin{tabular}[c]{|l|c|l|}
\hline
- Flag & Valore & Significato \\
+ \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\
\hline
\hline
\macro{S\_IFMT} & 0170000 & bitmask per i bit del tipo di file \\
pathname che contiene).
Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
-bytes. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
+byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
dimensione inferiore sarebbe inefficiente.
\label{sec:file_file_times}
Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
-nell'inode insieme agli altri attibuti del file e possono essere letti tramite
+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:
\begin{table}[htb]
\centering
+ \footnotesize
\begin{tabular}[c]{|c|l|l|c|}
\hline
- Membro & Significato & Funzione&opzione \\
+ \textbf{Membro} & \textbf{Significato} & \textbf{Funzione}
+ & \textbf{Opzione} \\
\hline
\hline
\var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\
\footnotesize
\begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
\hline
- \multicolumn{1}{|c|}{Funzione}
- &\multicolumn{3}{p{2cm}}{File o directory di riferimento}
- &\multicolumn{3}{p{2cm}}{Directory genitrice del riferimento}
- &\multicolumn{1}{|c|}{Note} \\
+ \multicolumn{1}{|p{3cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} &
+ \multicolumn{3}{|p{3cm}|}{\centering{File o directory di riferimento}}&
+ \multicolumn{3}{|p{3cm}|}{\centering{Directory genitrice del riferimento}}
+ &\multicolumn{1}{|p{3.6cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\
+ \cline{2-7}
\cline{2-7}
- & \textsl{(a)} & \textsl{(m)}& \textsl{(c)}
- & \textsl{(a)} & \textsl{(m)}& \textsl{(c)}& \\
+ \multicolumn{1}{|p{3cm}|}{}
+ &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
+ &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
+ &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
+ &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
+ &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
+ &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
+ &\multicolumn{1}{|p{3cm}|}{} \\
\hline
\hline
\func{chmod}, \func{fchmod}
& &$\bullet$&$\bullet$& & & & \\
\hline
\end{tabular}
- \caption{Effetti delle varie funzioni su tempi di ultimo accesso
- \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento
- \textsl{(c)}}
+ \caption{Prospetto dei cambiamenti effettuati sui tempi di ultimo
+ accesso \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento
+ \textsl{(c)} dalle varie funzioni operanti su file e directory.}
\label{tab:file_times_effects}
\end{table}
Per quanto dicevamo in \secref{sec:file_filesystem} la creazione del
collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
-il caso ad esempio del filesystem \texttt{vfat} di windows).
+il caso ad esempio del filesystem \texttt{vfat} di Windows).
La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
in alcuni filesystem solo l'amministratore è in grado di creare un
settata secondo i seguenti codici di errore:
\begin{errlist}
\item \texttt{EISDIR} \var{pathname} si riferisce ad una directory
- (valore specifico ritornato da linux che non consente l'uso di
+ (valore specifico ritornato da Linux che non consente l'uso di
\texttt{unlink} con le directory, e non conforme allo standard POSIX, che
prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia
consentita o il processo non abbia privilegi sufficienti).
\item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
già.
\item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
- su un filesystem montato readonly.
+ su un filesystem montato in sola lettura.
\item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
link è piena e non c'è ulteriore spazio disponibile.
\item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
\item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
già.
\item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
- su un filesystem montato readonly.
+ su un filesystem montato in sola lettura.
\item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
link è piena e non c'è ulteriore spazio disponibile.
\end{errlist}
\footnotesize
\begin{tabular}[c]{|l|c|c|}
\hline
- Funzione & Segue il link & Non segue il link \\
+ \textbf{Funzione} & \textbf{Segue il link} & \textbf{Non segue il link} \\
\hline
\hline
\func{access} & $\bullet$ & \\
(e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
visti dal sistema operativo.}.
-Questo può causare problemi per tutti quei programmi che effettuano lo scan di
-una directory senza tener conto dei link simbolici, ad esempio se lanciassimo
-un comando del tipo \cmd{grep -r linux *}, il loop nella directory porterebbe
-il comando ad esaminare \file{/boot}, \file/{boot/boot}, \file/{boot/boot/boot}
-e così via, fino a generare un errore (che poi è \macro{ELOOP}) quando viene
-superato il numero massimo di link simbolici consentiti (uno dei limiti del
-sistema, posto proprio per poter uscire da questo tipo di situazione).
+Questo può causare problemi per tutti quei programmi che effettuano la
+scansione di una directory senza tener conto dei link simbolici, ad esempio se
+lanciassimo un comando del tipo \cmd{grep -r linux *}, il loop nella directory
+porterebbe il comando ad esaminare \file{/boot}, \file/{boot/boot},
+\file/{boot/boot/boot} e così via, fino a generare un errore (che poi è
+\macro{ELOOP}) quando viene superato il numero massimo di link simbolici
+consentiti (uno dei limiti del sistema, posto proprio per poter uscire da
+questo tipo di situazione).
Un secondo punto da tenere presente è che un link simbolico può essere fatto
anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
\begin{verbatim}
$ ln -s /tmp/tmp_file temporaneo
\end{verbatim}%$
-ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura
-\file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola
-lettura (ad esempio con \cmd{cat}) otterremmo:
+ma anche se \file{/tmp/tmp\_file} non esiste (quello che viene chiamato un
+\textit{dangling link}, letteralemnte \textsl{link ciondolante}). Aprendo in
+scrittura \file{temporaneo} questo verrà scritto; ma se cercassimo di
+accederlo in sola lettura (ad esempio con \cmd{cat}) otterremmo:
\begin{verbatim}
-$ cat prova
-cat: prova: No such file or directory
+$ cat temporaneo
+cat: temporaneo: No such file or directory
\end{verbatim}%$
-con un errore che sembra sbagliato, dato \cmd{ls} ci mostrerebbe l'esistenza
-di \file{temporaneo}.
+con un errore che può sembrare sbagliato, dato \cmd{ls} ci mostrerebbe
+l'esistenza di \file{temporaneo}.
\subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
\label{sec:file_dir_creat_rem}
-Per creare una nuova directory si può usare la seguente funzione, omonima
-dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati
-programma deve includere il file \texttt{sys/types.h}.
+Queste due funzioni servono per creare e cancellare delle directory e sono
+omonime degli analoghi comandi di shell. Per poter accedere ai tipi usati
+da queste funzioni si deve includere il file \texttt{sys/types.h}, il
+protoripo della prima è:
\begin{prototype}{sys/stat.h}
-{int mkdir (const char * dirname, mode\_t mode)}
- Questa funzione crea una nuova directory vuota con il nome indicato da
- \var{dirname}, assegnandole i permessi indicati da \var{mode}. Il nome
- può essere indicato con il pathname assoluto o relativo.
+ {int mkdir (const char * dirname, mode\_t mode)}
+ Crea una nuova directory vuota con il nome indicato da \var{dirname},
+ assegnandole i permessi indicati da \var{mode}. Il nome può essere indicato
+ con il pathname assoluto o relativo.
- La funzione restituisce zero in caso di successo e -1 per un errore, in caso
- di errore \texttt{errno} viene settata secondo i codici di errore standard
- di accesso ai file (trattati in dettaglio in
- \secref{sec:file_access_control}) ai quali si aggiungono i seguenti:
+ La funzione restituisce zero in caso di successo e -1 per un errore, nel
+ qual caso \var{errno} assumerà i valori:
\begin{errlist}
+ \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già.
\item \texttt{EACCESS}
Non c'è il permesso di scrittura per la directory in cui si vuole inserire
la nuova directory.
- \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già.
\item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
contiene troppi file. Sotto Linux questo normalmente non avviene perché il
filesystem standard consente la creazione di un numero di file maggiore di
quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
fare anche con filesystem di altri sistemi questo errore può presentarsi.
\item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
- la nuova directory.
- \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
- directory è su un filesystem montato readonly.
+ la nuova directory o si è esaurita la quota disco dell'utente.
\end{errlist}
+ ed inoltre anche \macro{EPERM}, \macro{EFAULT}, \macro{ENAMETOOLONG},
+ \macro{ENOENT}, \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP},
+ \macro{EROFS}.
\end{prototype}
+
+\begin{prototype}{sys/stat.h}
+ {int rmdir (const char * dirname)}
+ Cancella la directory \var{dirname}, che deve essere vuota. Il nome può
+ essere indicato con il pathname assoluto o relativo.
+
+ La funzione restituisce zero in caso di successo e -1 per un errore, nel
+ qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item \texttt{EPERM} Il filesystem non supporta la cancellazione di
+ directory, oppure la directory che contiene \var{dirname} ha lo sticky bit
+ settato e l'\textit{effective user id} del processo non corrisponde al
+ proprietario della directory.
+ \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory che
+ contiene la directory che si vuole cancellare, o non c'è il permesso di
+ attraversare (esecuzione) una delle directory specificate in
+ \var{dirname}.
+ \item \texttt{EBUSY} La directory specificata è la directory di lavoro o la
+ radice di qualche processo.
+ \item \texttt{ENOTEMPTY} La directory non è vuota.
+ \end{errlist}
+ ed inoltre anche \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT},
+ \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, \macro{EROFS}.
+\end{prototype}
+
+
+
+
+
\subsection{Accesso alle directory}
\label{sec:file_dir_read}
\textit{directory streams} (chiamati così per l'analogia con i file stream);
la funzione \texttt{opendir} apre uno di questi stream e la funzione
\texttt{readdir} legge il contenuto della directory, i cui elementi sono le
-\textit{directory entries} (da distinguersi da quelle della cache di cui
+\textit{directory entry} (da distinguersi da quelle della cache di cui
parlavamo in \secref{sec:file_vfs}) in una opportuna struttura
\texttt{struct dirent}.
Di questa funzione esiste una versione \texttt{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 \texttt{PATH\_MAX} (di solito 256 bytes, vedi
+dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byte, vedi
\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
contenere il nome del file, e questa è la ragione principale per cui questa
projects / gapil.git / blobdiff