filedir.tex

   1 \chapter{Files e directories}
   2 \label{cha:files_and_dirs}
   3
   4 In questo capitolo tratteremo in dettaglio le varie caratteristiche di files e
   5 directories, ed in particolare approfondiremo i dettagli su come è organizzata
   6 la struttura dei files in un sistema unix; esamineremo poi come è strutturato
   7 il sistema base di protezioni e controllo di accesso ai files, e tutta
   8 l'interfaccia che permette la manipolazione dei vari attributi di files e
   9 directories. Tutto quello che riguarda invece la manipolazione dei contenuti e
  10 lasciato ai capitoli successivi.
  11
  12 Le funzioni che esamineremo in questo capitolo pertanto sono quelle che
  13 permettono di creare e cancellare o leggere le directories, rinominare o
  14 cancellare i files ed esaminare o cambiare i loro attributi.
  15
  16
  17 \section{L'organizzazione di files e directories}
  18 \label{sec:filedir_org}
  19
  20 L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
  21 medesimi nell'albero descritto brevemente in \ref{sec:fileintr_overview}; una
  22 directory comunque, come già specificato in \ref{sec:fileintr_vfs}, è solo un
  23 particolare tipo di file che contiene le informazioni che associano un nome al
  24 contenuto. Per questo, anche se è usuale parlare di ``file in una directory''
  25 in realtà una directory contiene solo dei riferimenti ai file, non i file
  26 stessi.
  27
  28 I nomi contenuti nelle directory sono chiamati componenti (\textit{file name
  29   components}), un file può essere indicato rispetto alla directory corrente
  30 semplicemente specificando il nome da essa contenuto. Una directory contiene
  31 semplicemente un elenco di questi componenti, che possono corrispondere a un
  32 qualunque oggetto del filesystem, compresa un'altra directory; l'albero viene
  33 appunto creato inserendo directory in altre directory.
  34
  35 Il nome di file generico è composto da una serie di \textsl{componenti}
  36 separati da una \texttt{/} (in linux più \texttt{/} consecutive sono
  37 considerate equivalenti ad una sola). Il nome completo di un file viene
  38 usualmente chiamato \textit{pathname}, e anche se il manuale della glibc
  39 depreca questo nome (poichè genererebbe confusione, dato che con \textit{path}
  40 si indica anche un insieme di directory su cui effettuare una ricerca, come
  41 quello in cui si cercano i comandi) l'uso è ormai così comune che è senz'altro
  42 più chiaro dell'alternativa proposta.
  43
  44 Il processo con cui si associa ad un pathname uno specifico file (cioè si
  45 identifica l'inode a cui fare riferimento) è chiamato risoluzione del nome
  46 (\textit{file name resolution} o \textit{pathname resolution}).
  47 La risoluzione viene fatta esaminando il pathname da destra a sinistra e
  48 localizzando ogni componente nella directory indicata dal componente
  49 precedente: ovviamente perché il procedimento funzioni occorre che i
  50 componenti indicati come directory esistano e siano effettivamente directory,
  51 inoltre i permessi devono consentire l'accesso.
  52
  53 Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
  54 del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
  55 seguito, vedi \ref{sec:proc_chroot}) è la stessa per tutti i processi ed
  56 equivale alla directory radice dell'albero (come descritto in
  57 \ref{sec:fileintr_overview}): in questo caso si parla di un pathname
  58 \textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
  59 cui torneremo più avanti in \ref{sec:filedir_work_dir}) ed il pathname è detto
  60 \textsl{relativo}.
  61
  62 I componenti \texttt{.} e \texttt{..} hanno un significato speciale e vengono
  63 inseriti in ogni directory, il primo fa riferimento alla directory corrente e
  64 il secondo alla directory \textsl{genitore} (\textit{parent directory}) cioè
  65 la directory che contiene il riferimento alla directory corrente; nel caso
  66 questa sia la directory radice allora il riferimento è a se stessa.
  67
  68
  69 \section{La manipolazione di files e directories}
  70 \label{sec:filedir_handling}
  71
  72 Per capire fino in fondo le proprietà di files e directories in un sistema
  73 unix ed il funzionamento delle relative funzioni di manipolazione occorre una
  74 breve introduzione agli oggetti su cui è basato un filesystem unix; in
  75 particolare si riprenderanno, approfondendoli, i concetti di \textit{inode} e
  76 \textit{dentry} brevemente introdotti in \ref{sec:fileintr_vfs}.
  77
  78
  79 \subsection{Il funzionamento di un filesystem}
  80 \label{sec:filedir_filesystem}
  81
  82 Come già accennato in \ref{sec:fileintr_overview} linux (ed ogni unix in
  83 generale) organizza i dati che tiene su disco attraverso l'uso di un
  84 filesystem. Una delle caratteristiche di linux rispetto agli altri unix è
  85 quella di poter supportare grazie al VFS una enorme quantità di filesystem
  86 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
  87 proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
  88 daremo una descrizione a grandi linee che si adatta alle caratteristiche
  89 comuni di un qualunque filesystem standard unix.
  90
  91 Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
  92 partizione può contenere un filesystem; quest'ultimo è in genere strutturato
  93 secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio aa
  94 disposizione per i dati e le directory.
  95
  96 \begin{figure}[htb]
  97   \centering
  98
  99   \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
 100   \label{fig:filedir_disk_filesys}
 101 \end{figure}
 102
 103 Se si va ad esaminare come è strutturata l'informazione all'interno del
 104 filesystem (tralasciando le parti che non riguardano direttamente la gestione
 105 di file e directory come il super-block) avremo una situazione del tipo di
 106 quella esposta in \nfig.
 107
 108 \begin{figure}[htb]
 109   \centering
 110
 111   \caption{Organizzazione di un filesystem}
 112   \label{fig:filedir_filesys_detail}
 113 \end{figure}
 114
 115
 116 Quanto mostrato in \curfig\ mette in evidenza alcune caratteristiche di un
 117 filesystem unix su cui è bene porre attenzione in quanto sono fondamentali per
 118 capire il funzionamento delle funzioni che manipolano i file e le directory su
 119 cui torneremo fra poco; in particolare è opportuno ricordare sempre che:
 120
 121 \begin{itemize}
 122
 123 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
 124   tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
 125   fisici che contengono i dati e così via; le informazioni che la funzione
 126   \texttt{stat} fornisce provengono dall'inode; dentro una directory si
 127   troverà solo il nome del file e il numero dell'inode ad esso associato, cioè
 128   una \textit{dentry}.
 129
 130 \item Come mostrato in \curfig si possono avere più dentries che puntano allo
 131   stesso inode. Ogni inode ha un contatore che contiene il numero di
 132   riferimenti (\textit{link count}) che sono stati fatti ad esso, solo quando
 133   questo contatore si annulla il file può essere cancellato. Per questo in
 134   generale non esiste una funzione che cancelli un file, ma solo la funzione
 135   \texttt{unlink} che si chiama così proprio perché che toglie un riferimento
 136   da una directory (cancellando la dentry), il che non comporta
 137   automaticamente pure la eliminazione dei blocchi sul disco.
 138
 139 \item Siccome il numero di inode nella dentry si riferisce ad un inode nello
 140   stesso filesystem non ci può essere una directory che contiene riferimenti
 141   ad inodes relativi ad altri filesystem, questo limita l'uso del comando
 142   \texttt{ln} (che crea una nuova dentry per un file esistente, con la
 143   funzione \texttt{link}) al filesystem corrente.
 144
 145 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
 146   del file non deve essere spostato, ma basta creare una nuova dentry per
 147   l'inode in questione rimuovendo la vecchia (che è la modalità in cui opera
 148   normalmente il comando \texttt{mv} attraveso la funzione \texttt{rename}).
 149
 150 \end{itemize}
 151
 152 Infine è bene avere presente che esiste un numero di riferimenti anche per le
 153 directories, se a partire dalla situazione mostrata in \curfig\ creiamo una
 154 nuova directory \texttt{textdir} avremo una situazione come quella in \nfig,
 155 dove per chiarezza abbiamo aggiunto dei numeri di inode.
 156
 157 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
 158 è referenziata dalla directory da cui si era partiti (in cui è inserita la
 159 nuova dentry che fa riferiemto a \texttt{textdir}) e dalla dentry \texttt{.}
 160 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
 161 che non contenga a sua volta altre directories. Al contempo la directory da
 162 cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
 163 adesso sarà referenziata anche dalla dentry \texttt{..} di \texttt{textdir}.
 164
 165
 166 \subsection{Le funzioni \texttt{link} e \texttt{unlink}}
 167 \label{sec:filedir_link}
 168
 169 Una delle caratteristiche usate quando si opera con i file è quella di poter
 170 creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
 171 stesso file accedendovi da directory diverse. Questo è possibile anche in
 172 ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
 173 ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
 174 per fare questa operazione.
 175
 176 Come si è appena visto l'accesso al contenuto di un file su disco avviene
 177 attraverso il suo \textit{inode}, e il nome che si trova in una directory è
 178 solo una etichetta associata ad un puntatore a detto inode.  Questo significa
 179 che la realizzazione di un link è immediata in quanto uno stesso file può
 180 avere tanti nomi diversi allo stesso tempo, dati da altrettante diverse
 181 associazioni allo stesso inode; si noti poi che nessuno di questi nomi viene
 182 ad assumere una particolare preferenza rispetto agli altri.
 183
 184 Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
 185 suole chiamare questo tipo di associazione un collegamento diretto (o
 186 \textit{hard link}).  La creazione di un nuovo link diretto non copia il
 187 contenuto del file, ma si limita ad aumentare di uno il numero di referenze al
 188 file aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
 189 essere così richiamato in diverse directory.
 190
 191 \begin{itemize}
 192 \item \texttt{int link(const char * oldname, const char * newname)}
 193
 194   Crea un nuovo link diretto al file indicato da \texttt{oldname} dandogli
 195   nome \texttt{newname}.
 196
 197   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
 198   di errore. La variabile \texttt{errno} viene settata secondo i codici di
 199   errore standard di accesso ai files (trattati in dettaglio in
 200   \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
 201
 202   \begin{itemize}
 203   \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
 204     stesso filesystem.
 205   \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
 206     \texttt{newname} non supporta i link diretti.
 207   \item \texttt{EACCESS}
 208     Non c'è il permesso di scrittura per la directory in cui si vuole creare
 209     il nuovo link.
 210   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
 211     già.
 212   \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
 213     numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
 214     \ref{sec:xxx_limits}.
 215   \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
 216     non può essere ampliata.
 217   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
 218     su un filesystem montato readonly.
 219   \end{itemize}
 220 \end{itemize}
 221
 222
 223
 224 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
 225 \label{sec:filedir_cre_canc}
 226
 227
 228 \subsection{I link simbolici}
 229 \label{sec:filedir_sym_link}
 230
 231 Siccome tutto ciò funziona facendo riferimento ad un inode, questa funzione
 232 può essere applicata soltanto per file che risiedono sullo stesso filesystem,
 233 (dato che solo in questo caso è garantita l'unicità dell'inode) e solo per
 234 filesystem di tipo unix. Inoltre in linux non è consentito eseguire un link
 235 diretto ad una directory.
 236
 237 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
 238 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
 239 come avviene in altri sistemi operativi, dei file che contengono il
 240 semplicemente il riferimento ad un altro file (o directory). In questo modo è
 241 possibile effettuare link anche attraverso filesystem diversi e a directory, e
 242 pure a file che non esistono ancora.
 243
 244 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
 245 al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
 246 ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
 247 lettura del contenuto del medesimo e l'applicazione della funzione al file
 248 specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
 249 o rinominare i file operano direttamente sul link simbolico. Inoltre esistono
 250 funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere
 251 alle informazioni del link invece che a quelle del file a cui esso fa
 252 riferimento.
 253
 254 Le funzioni per operare sui link sono le seguenti, esse sono tutte dichiarate
 255 nell'header file \texttt{unistd.h}.
 256
 257 \begin{itemize}
 258 \item \texttt{int symlink(const char * oldname, const char * newname)}
 259
 260   Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
 261   nome \texttt{newname}.
 262
 263   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
 264   di errore. La variabile \texttt{errno} viene settata secondo i codici di
 265   errore standard di accesso ai files (trattati in dettaglio in
 266   \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
 267
 268   \begin{itemize}
 269   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
 270     già.
 271   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
 272     su un filesystem montato readonly.
 273   \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
 274     link è piena e non c'è ulteriore spazio disponibile.
 275   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
 276     \texttt{oldname} o di \texttt{newname}.
 277   \end{itemize}
 278 \end{itemize}
 279
 280
 281 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
 282 \label{sec:filedir_dir_creat_rem}
 283
 284 Per creare una nuova directory si può usare la seguente funzione, omonima
 285 dell'analogo comando di shell \texttt{mkdir}; per accedere alla funzioni il
 286 programma deve includere il file \texttt{sys/stat.h}.
 287
 288 \begin{itemize}
 289 \item \texttt{char * mkdir (const char * dirname, mode\_t mode)}
 290
 291   Questa funzione crea una nuova directory vuota con il nome indicato da
 292   \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
 293   può essere indicato con il pathname assoluto o relativo.
 294
 295   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
 296   di errore \texttt{errno} viene settata secondo i codici di errore standard
 297   di accesso ai files (trattati in dettaglio in
 298   \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
 299   \begin{itemize}
 300   \item \texttt{EACCESS}
 301     Non c'è il permesso di scrittura per la directory in cui si vuole inserire
 302     la nuova directory.
 303   \item \texttt{EEXIST} Un file (o una directory) con quel nome essite di già.
 304   \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
 305     contiene troppi file. Sotto linux questo normalmente non avviene perchè il
 306     filesystem standard consente la creazione di un numero di file maggiore di
 307     quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
 308     fare anche con filesystem di altri sistemi questo errore può presentarsi.
 309   \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
 310     la nuova directory.
 311   \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
 312     directory è su un filesystem montato readonly.
 313   \end{itemize}
 314 \end{itemize}
 315
 316
 317 \subsection{Accesso alle directory}
 318 \label{sec:filedir_dir_read}
 319
 320 Benchè le directory siano oggetti del filesystem come tutti gli altri non ha
 321 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
 322 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
 323 contengono o ricerche sui medesimi.
 324
 325 Per accedere al contenuto delle directory si usano i cosiddetti
 326 \textit{directory streams} (chiamati così per l'analogia con i file stream);
 327 la funzione \texttt{opendir} apre uno di questi stream e la funzione
 328 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
 329 \textit{directory entries} (da distinguersi da quelle della cache di cui
 330 parlavamo in \ref{sec:fileintr_vfs}) in una opportuna struttura
 331 \texttt{struct dirent}.
 332
 333
 334 \subsection{La directory di lavoro}
 335 \label{sec:filedir_work_dir}
 336
 337 A ciascun processo è associato ad una directory nel filesystem che è chiamata
 338 directory corrente o directory di lavoro (\textit{current working directory})
 339 che è quella a cui si fa riferimento quando un filename è espresso in forma
 340 relativa (relativa appunto a questa directory).
 341
 342 Quando un utente effettua il login questa directory viene settata alla
 343 cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
 344 della shell consente di cambiarla a piacere, spostandosi da una directory ad
 345 un'altra.  Siccome la directory corrente resta la stessa quando viene creato
 346 un processo figlio, la directory corrente della shell diventa anche la
 347 directory corrente di qualunque comando da essa lanciato.
 348
 349 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
 350 corrente. I prototipi di queste funzioni sono dichiarati in \texttt{unistd.h}.
 351
 352 \begin{itemize}
 353 \item \texttt{char * getcwd (char * buffer, size\_t size)}
 354
 355   Restituisce il filename completo della directory di lavoro corrente nella
 356   stringa puntata da \texttt{buffer}, che deve essere precedentemente
 357   allocata, per una dimensione massima di \texttt{size}. Si può anche
 358   specificare un puntatore nullo come \textit{buffer}, nel qual caso la
 359   stringa sarà allocata automaticamente per una dimensione pari a
 360   \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
 361   del pathname altrimenti. In questo caso si deve ricordare di disallocara la
 362   stringa una volta cessato il suo utilizzo.
 363
 364   La funzione restituisce il puntatore \texttt{buffer} se riesce,
 365   \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
 366   \texttt{errno} è settata con i seguenti codici di errore:
 367
 368   \begin{itemize}
 369   \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
 370     è nullo.
 371   \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
 372     lunghezza del pathname.
 373   \item \texttt{EACCES} Manca il permesso di lettura o di ricerca su uno dei
 374     componenti del pathname (cioè su una delle directory superiori alla
 375     corrente).
 376   \end{itemize}
 377 \end{itemize}
 378
 379 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
 380 fatta per compatibilità all'indietro con BSD, che non consente di specificare
 381 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
 382 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byters, vedi
 383 \ref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
 384 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
 385 contenere il nome del file, e questa è la ragione principale per cui questa
 386 funzione è deprecata.
 387
 388 Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
 389 che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
 390 differenza che essa ritorna il valore della variabile di ambiente
 391 \texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
 392 riferimenti simbolici.
 393
 394 Come già detto in unix anche le directory sono file, è possibile pertanto
 395 riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
 396 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
 397 per cambiare directory di lavoro.
 398
 399 \begin{itemize}
 400 \item \texttt{int chdir (const char * pathname)}
 401
 402   Come dice il nome (che significa \textit{change directory}) questa funzione
 403   serve a cambiare la directory di lavoro a quella speficata dal pathname
 404   contenuto nella stringa \texttt{pathname}.
 405
 406 \item \texttt{int fchdir (int filedes)} analoga alla precedente, ma usa un
 407   file descriptor invece del pathname.
 408
 409
 410   Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
 411   errore, in caso di errore \texttt{errno} viene settata secondo i codici di
 412   errore standard di accesso ai files (trattati in dettaglio in
 413   \ref{sec:filedir_access_control}) ai quali si aggiunge il codice
 414   \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
 415   una directory.
 416 \end{itemize}
 417
 418
 419
 420
 421
 422 \section{La manipolazione delle caratteristiche dei files}
 423 \label{sec:filedir_infos}
 424
 425
 426 Si ricordi che in unix non esistono i tipi di file e che non c'è nessun
 427 supporto per le estensioni come parte del filesystem. Ciò non ostante molti
 428 programmi adottano delle convenzioni per i nomi dei file, ad esempio il codice
 429 C normalmente si mette in file con l'estensione .c, ma questa è, appunto, solo
 430 una convenzione.
 431
 432
 433 \subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
 434 \label{sec:filedir_stat}
 435
 436 \subsection{I tipi di file}
 437 \label{sec:filedir_file_types}
 438
 439 \subsection{La dimensione dei file}
 440 \label{sec:filedir_file_size}
 441
 442 \subsection{I tempi dei file}
 443 \label{sec:filedir_file_times}
 444
 445 \subsection{La funzione \texttt{utime}}
 446 \label{sec:filedir_utime}
 447
 448
 449
 450 \section{Il controllo di accesso ai file}
 451 \label{sec:filedir_access_control}
 452
 453
 454 \subsection{I flag \texttt{suid} e \texttt{sgid}}
 455 \label{sec:filedir_suid_sgid}
 456
 457 \subsection{La titolarità di nuovi files e directory}
 458 \label{sec:filedir_ownership}
 459
 460 \subsection{La funzione \texttt{access}}
 461 \label{sec:filedir_access}
 462
 463 \subsection{La funzione \texttt{umask}}
 464 \label{sec:filedir_umask}
 465
 466 \subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
 467 \label{sec:filedir_chmod}
 468
 469 \subsection{Il flag \texttt{stiky}}
 470 \label{sec:filedir_stiky}
 471
 472 \subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
 473 \label{sec:filedir_chown}
 474
 475
 476
 477 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
 478 %cosiddetto \textit{inode}; questo conterrà informazioni come il
 479 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
 480 %completo vedi \ntab), i permessi (vedi \ref{sec:file_perms}), le date (vedi
 481 %\ref{sec:file_times}).
 482