Sto leggendo questo tutorial Unix e ho trovato questa citazione ...
Dovremmo notare qui che una directory è semplicemente un tipo speciale di file.
... ma non vengono fornite spiegazioni o dettagli. In che modo una directory è davvero solo un file?
Risposte:
Molte entità nei sistemi operativi * nix (e altri) sono considerate file o hanno un aspetto simile a un file, anche se non sono necessariamente una sequenza di byte archiviati in un filesystem. L'esatta implementazione delle directory dipende dal tipo di filesystem, ma generalmente ciò che contengono, considerato come un elenco, è una sequenza di byte memorizzati, quindi in quel senso non sono così speciali.
Un modo per definire cosa sia un "file" in un contesto * nix è che è qualcosa a cui è associato un descrittore di file . Secondo l'articolo di Wikipedia, un descrittore di file
è un indicatore astratto utilizzato per accedere a un file o ad altre risorse di input / output , come una pipe o una connessione di rete ...
In altre parole, si riferiscono a vari tipi di risorse da / a cui una sequenza di byte può essere letta / scritta, sebbene l'origine / destinazione di quella sequenza non sia specificata. Detto in altro modo, il "dove" della risorsa potrebbe essere qualsiasi cosa. Ciò che lo definisce è che è un condotto di informazione. Questo è parte del motivo per cui a volte si dice che in unix "tutto è un file". Non dovresti prenderlo completamente alla lettera, ma vale la pena prendere in seria considerazione. Nel caso di una directory, queste informazioni riguardano ciò che si trova nella directory e, a un livello di implementazione inferiore, come trovarlo nel filesystem.
Le directory sono in qualche modo speciali in questo senso perché nel codice C nativo non sono apparentemente associate a un descrittore di file; POSIX API utilizza un particolare tipo di maniglia flusso, DIR*. Tuttavia, questo tipo ha in effetti un descrittore sottostante che può essere recuperato . I descrittori sono gestiti dal kernel e accedervi comporta sempre chiamate di sistema, quindi un altro aspetto di ciò che è un descrittore è che è un condotto controllato dal kernel del sistema operativo. Hanno numeri univoci (per processo) che iniziano con 0, che di solito è il descrittore per il flusso di input standard .
openat, fstatat, ecc), che utilizzano i descrittori di file che si riferiscono alle directory.
fsync()una directory di sola lettura (!) Fd, e ha un effetto ben definito (in particolare, sincronizza la creazione / la ridenominazione / eliminazione dei file nella directory data su disco, un passaggio teoricamente necessario nella "scrittura in un file temporaneo e rinominarlo nell'originale "linguaggio".
Nel modo Unix di fare le cose: tutto è un file.
Una directory è uno (di molti) tipi di file speciali. Non contiene dati. Al contrario, contiene i puntatori a tutti i file contenuti nella directory.
Altri tipi di file speciali:
Ma poiché sono considerati "file", è possibile lseseguirli, rinominarli, spostarli e, a seconda del tipo di file speciale, inviare dati da / a loro.
La mia risposta è semplice reminescenza, ma negli Unix vintage 199x, di cui ce n'erano molti, le directory erano file, appena contrassegnati "directory" da qualche parte nell'inode su disco.
È possibile aprire una directory con qualcosa di simile open(".", O_RDONLY)e ottenere un descrittore di file utilizzabile. È possibile analizzare il contenuto se si scorre attraverso /usr/includee si trova la corretta definizione di C struct. So di averlo fatto per i sistemi SunOS 4.1.x, il filesystem EFS di SGI e qualunque altra workstation Mips-CPU di DEC avesse avuto per un filesystem, probabilmente BSD4.2 FFS.
È stata una brutta esperienza. La standardizzazione su un livello di filesystem virtuale è una buona cosa per la portabilità, anche se le directory non sono più file rigorosi. I livelli VFS ci consentono di sperimentare file system in cui le directory non sono file, come ReiserFS o NFS.
cp --link dir1/* dir2, anche se non sono sicuro della sua usabilità.
Una directory è speciale in quanto ha la 'd' nella sua modalità, dicendo al filesystem che dovrebbe interpretare il suo contenuto come un elenco di altri file contenuti nella directory, piuttosto che un normale file che è solo una sequenza di byte da letto dall'applicazione. Questo è tutto.
Le directory sono file perché i sistemi Linux utilizzano un modello di I / O universale . Nel modello tutto nel sistema è un file ed è possibile accedervi con le stesse chiamate di sistema e vari comandi.
Sono di tipo speciale perché i loro i-nodi hanno il segno per il tipo di file e hanno una struttura speciale di essere una tabella di nomi di file e collegamenti ad altri i-nodi. Queste coppie nome-link, note anche come "hardlink", nell'i-nodo di una directory enumerano i file "all'interno" della directory.
Le directory servono solo per organizzare i file. Quando un file viene "spostato" da una directory a un'altra, il file stesso non viene spostato nel disco. È solo che una voce in una directory i-node viene rimossa e scritta in un'altra directory i-node.
La risposta accettata non è completamente corretta. nei sistemi POSIX, "Inodes" indicano file e directory. I descrittori di file sono unici per un processo e non per un sistema. Gli Inodi sono tuttavia unici, sebbene più di un inode possa puntare a un singolo file. Avrebbe commentato la risposta accettata, ma non potevo a causa della restrizione del rappresentante.
ls -l >test.txt;ln -vf test.txt test2.txt;ls -li test.txt test2.txt. Quindi vedrai che gli hard link hanno lo stesso numero di inode.
fork()è, il suo processo figlio avrà (tranne qualche circostanza speciale, vale a dire una O_CLOEXECbandiera) esattamente le stesse entità archiviate del processo originale. Un altro esempio: i processi figlio di Apache sono listen()presenti nello stesso descrittore di file socket. Ma questa risposta non riguarda i descrittori di file, che sono una struttura di dati interna al kernel ed esistono solo nella memoria del kernel. Questa ( falsa ) risposta riguarda le voci della directory e gli inode, queste sono entità su disco (cioè sono byte fisici sul disco rigido).
fork()accada e quindi il processo figlio seek()s o close()s, non influenzerà il file descrittore del genitore. Quindi sto pensando ora che i descrittori di file sono solo parzialmente strutture di processo private. Ma questa domanda non riguarda loro, questa domanda riguarda le direzioni / inode e ti sto commentando su una risposta completamente falsa a questa domanda.