%% filedir.tex
%%
-%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2017 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e
\kstruct{file\_operation}. Ovviamente non è detto che tutte le operazioni
possibili siano poi disponibili in tutti i casi, ad esempio \code{llseek} non
-sarà presente per un dispositivo come la porta seriale o per una fifo, mentre
-sui file del filesystem \texttt{vfat} non saranno disponibili i permessi, ma
-resta il fatto che grazie al VFS le \textit{system call} per le operazioni sui
-file possono restare sempre le stesse nonostante le enormi differenze che
-possono esserci negli oggetti a cui si applicano.
+sarà presente per un dispositivo come la porta seriale o per una
+\textit{fifo}, mentre sui file del filesystem \texttt{vfat} non saranno
+disponibili i permessi, ma resta il fatto che grazie al VFS le \textit{system
+ call} per le operazioni sui file possono restare sempre le stesse nonostante
+le enormi differenze che possono esserci negli oggetti a cui si applicano.
\itindend{Virtual~File~System~(VFS)}
directory che lo contiene e decrementa il numero di riferimenti nel relativo
\textit{inode}.\footnote{come per \func{link} queste due operazioni sono
effettuate all'interno della \textit{system call} in maniera atomica.} Nel
-caso di socket, fifo o file di dispositivo rimuove il nome, ma come per i file
-normali i processi che hanno aperto uno di questi oggetti possono continuare
-ad utilizzarli. Nel caso di cancellazione di un collegamento simbolico, che
-consiste solo nel rimando ad un altro file, questo viene immediatamente
-eliminato.
+caso di socket, \textit{fifo} o file di dispositivo rimuove il nome, ma come
+per i file normali i processi che hanno aperto uno di questi oggetti possono
+continuare ad utilizzarli. Nel caso di cancellazione di un collegamento
+simbolico, che consiste solo nel rimando ad un altro file, questo viene
+immediatamente eliminato.
Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
della stringa.
Per quanto riguarda il significato dei campi opzionali, il campo \var{d\_type}
-indica il tipo di file (se fifo, directory, collegamento simbolico, ecc.), e
-consente di evitare una successiva chiamata a \func{lstat} (vedi
+indica il tipo di file (se \textit{fifo}, directory, collegamento simbolico,
+ecc.), e consente di evitare una successiva chiamata a \func{lstat} (vedi
sez.~\ref{sec:file_stat}) per determinarlo. I suoi possibili valori sono
riportati in tab.~\ref{tab:file_dtype_macro}. Si tenga presente che questo
valore è disponibile solo per i filesystem che ne supportano la restituzione
\constd{DT\_REG} & File normale.\\
\constd{DT\_DIR} & Directory.\\
\constd{DT\_LNK} & Collegamento simbolico.\\
- \constd{DT\_FIFO} & Fifo.\\
+ \constd{DT\_FIFO} & \textit{Fifo}.\\
\constd{DT\_SOCK} & Socket.\\
\constd{DT\_CHR} & Dispositivo a caratteri.\\
\constd{DT\_BLK} & Dispositivo a blocchi.\\
Finora abbiamo parlato esclusivamente di file, directory e collegamenti
simbolici, ma in sez.~\ref{sec:file_file_types} abbiamo visto che il sistema
prevede anche degli altri tipi di file, che in genere vanno sotto il nome
-generico di \textsl{file speciali}, come i file di dispositivo, le fifo ed i
+generico di \textsl{file speciali}, come i file di dispositivo, le \textit{fifo} ed i
socket.
La manipolazione delle caratteristiche di questi file speciali, il cambiamento
\item[\errcode{EEXIST}] \param{pathname} esiste già o è un collegamento
simbolico.
\item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
- fifo, un socket o un dispositivo.
+ \textit{fifo}, un socket o un dispositivo.
\item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare
l'\texttt{inode}, o il filesystem su cui si è cercato di
creare \param{pathname} non supporta l'operazione.
\const{S\_IFREG} per un file regolare (che sarà creato vuoto),
\const{S\_IFBLK} per un dispositivo a blocchi, \const{S\_IFCHR} per un
dispositivo a caratteri, \const{S\_IFSOCK} per un socket e \const{S\_IFIFO}
-per una fifo;\footnote{con Linux la funzione non può essere usata per creare
- directory o collegamenti simbolici, si dovranno usare le funzioni
+per una \textit{fifo};\footnote{con Linux la funzione non può essere usata per
+ creare directory o collegamenti simbolici, si dovranno usare le funzioni
\func{mkdir} e \func{symlink} a questo dedicate.} un valore diverso
comporterà l'errore \errcode{EINVAL}. Inoltre \param{pathname} non deve
esistere, neanche come collegamento simbolico.
mentre è presente in SVr4 e 4.4BSD, ma esistono differenze nei comportamenti
e nei codici di errore, tanto che questa è stata introdotta in POSIX.1-2001
con una nota che la definisce portabile solo quando viene usata per creare
- delle fifo, ma comunque deprecata essendo utilizzabile a tale scopo la
- specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di
-una fifo o di un socket è consentito anche agli utenti normali.
+ delle \textit{fifo}, ma comunque deprecata essendo utilizzabile a tale scopo
+ la specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di
+una \textit{fifo} o di un socket è consentito anche agli utenti normali.
I nuovi \textit{inode} creati con \func{mknod} apparterranno al proprietario e
al gruppo del processo (usando \ids{UID} e \ids{GID} del gruppo effettivo) che
Dato che la funzione di sistema \func{mknod} presenta diverse varianti nei
vari sistemi unix-like, lo standard POSIX.1-2001 la dichiara portabile solo in
-caso di creazione delle fifo, ma anche in questo caso alcune combinazioni
-degli argomenti restano non specificate, per cui nello stesso standard è stata
-introdotta una funzione specifica per creare una fifo deprecando l'uso di
-\func{mknod} a tale riguardo. La funzione è \funcd{mkfifo} ed il suo
-prototipo è:
+caso di creazione delle \textit{fifo}, ma anche in questo caso alcune
+combinazioni degli argomenti restano non specificate, per cui nello stesso
+standard è stata introdotta una funzione specifica per creare una
+\textit{fifo} deprecando l'uso di \func{mknod} a tale riguardo. La funzione è
+\funcd{mkfifo} ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/stat.h}
\fdecl{int mkfifo(const char *pathname, mode\_t mode)}
-\fdesc{Crea una fifo.}
+\fdesc{Crea una \textit{fifo}.}
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà \errval{EACCES}, \errval{EEXIST},
\errval{EROFS} nel loro significato generico.}
\end{funcproto}
-La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come
-per \func{mknod} il file \param{pathname} non deve esistere (neanche come
-collegamento simbolico); al solito i permessi specificati da \param{mode}
-vengono modificati dal valore di \textit{umask} (vedi
-sez.~\ref{sec:file_perm_management}).
+La funzione crea la \textit{fifo} \param{pathname} con i
+permessi \param{mode}. Come per \func{mknod} il file \param{pathname} non deve
+esistere (neanche come collegamento simbolico); al solito i permessi
+specificati da \param{mode} vengono modificati dal valore di \textit{umask}
+(vedi sez.~\ref{sec:file_perm_management}).
\index{file!speciali|)}
\end{itemize*}
+% TODO trattare anche statx, aggiunta con il kernel 4.11 (vedi
+% https://lwn.net/Articles/707602/ e
+% https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f)
\subsection{I tipi di file}
\macrod{S\_ISDIR}\texttt{(m)} & Directory.\\
\macrod{S\_ISCHR}\texttt{(m)} & Dispositivo a caratteri.\\
\macrod{S\_ISBLK}\texttt{(m)} & Dispositivo a blocchi.\\
- \macrod{S\_ISFIFO}\texttt{(m)} & Fifo.\\
+ \macrod{S\_ISFIFO}\texttt{(m)} & \textit{Fifo}.\\
\macrod{S\_ISLNK}\texttt{(m)} & Collegamento simbolico.\\
\macrod{S\_ISSOCK}\texttt{(m)} & Socket.\\
\hline
\constd{S\_IFBLK} & 0060000 & Dispositivo a blocchi.\\
\constd{S\_IFDIR} & 0040000 & Directory.\\
\constd{S\_IFCHR} & 0020000 & Dispositivo a caratteri.\\
- \constd{S\_IFIFO} & 0010000 & Fifo.\\
+ \constd{S\_IFIFO} & 0010000 & \textit{Fifo}.\\
\hline
\constd{S\_ISUID} & 0004000 & Set user ID (\acr{suid}) bit, vedi
sez.~\ref{sec:file_special_perm}).\\
una struttura \struct{stat} contiene la dimensione del file in byte. Questo
però è vero solo se si tratta di un file regolare, mentre nel caso di un
collegamento simbolico la dimensione è quella del \textit{pathname} che il
-collegamento stesso contiene, infine per le fifo ed i file di dispositivo
+collegamento stesso contiene, infine per le \textit{fifo} ed i file di dispositivo
questo campo è sempre nullo.
Il campo \var{st\_blocks} invece definisce la lunghezza del file in blocchi di
due casi hanno a che fare con il contenuto del file, e nella discussione
relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
capace di indicare una qualche forma sensata di utilizzo degli stessi per
- collegamenti simbolici o file di dispositivo, e neanche per le fifo o i
+ collegamenti simbolici o file di dispositivo, e neanche per le \textit{fifo} o i
socket. Per questo motivo essi sono stati completamente disabilitati per
tutto ciò che non sia un file regolare o una directory.\footnote{si può
verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
}
\end{funcproto}
-La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+La funzione è del tutto è analoga a \func{acl\_set\_file} ma opera
esclusivamente sui file identificati tramite un file descriptor. Non dovendo
avere a che fare con directory (e con la conseguente possibilità di avere una
ACL di default) la funzione non necessita che si specifichi il tipo di ACL,