Je lis ce tutoriel Unix et suis tombé sur cette citation ...
Notons ici qu'un répertoire n'est qu'un type de fichier spécial.
... mais aucune explication ou détail n'est fourni. Comment un répertoire est-il vraiment juste un fichier?
Réponses:
De nombreuses entités dans les systèmes d'exploitation de style * nix (et autres) sont considérées comme des fichiers ou ont un aspect de type fichier, même si elles ne sont pas nécessairement une séquence d'octets stockée dans un système de fichiers. La façon exacte dont les répertoires sont implémentés dépend du type de système de fichiers, mais généralement ce qu'ils contiennent, considéré comme une liste, est une séquence d'octets stockés, donc en ce sens, ils ne sont pas si spéciaux.
Une façon de définir ce qu'est un "fichier" dans un contexte * nix est qu'il s'agit d'un élément auquel un descripteur de fichier est associé. Selon l'article de wikipedia, un descripteur de fichier
est un indicateur abstrait utilisé pour accéder à un fichier ou à une autre ressource d'entrée / sortie , comme un tuyau ou une connexion réseau ...
En d'autres termes, ils se réfèrent à différents types de ressources à partir desquelles une séquence d'octets peut être lue / écrite, bien que la source / destination de cette séquence ne soit pas spécifiée. Autrement dit, le «où» de la ressource pourrait être n'importe quoi. Ce qui le définit, c'est qu'il est un canal d'information. C'est en partie pourquoi il est parfois dit que sous unix "tout est un fichier". Vous ne devriez pas prendre cela complètement au pied de la lettre, mais cela mérite une sérieuse considération. Dans le cas d'un répertoire, ces informations concernent ce qui se trouve dans le répertoire et, à un niveau d'implémentation inférieur, comment le trouver dans le système de fichiers.
Les répertoires sont en quelque sorte spéciaux dans ce sens car dans le code C natif, ils ne sont pas ostensiblement associés à un descripteur de fichier; l'API utilise POSIX un type spécial de la poignée de flux, DIR*. Cependant, ce type a en fait un descripteur sous-jacent qui peut être récupéré . Les descripteurs sont gérés par le noyau et y accéder implique toujours des appels système, par conséquent, un autre aspect de ce qu'est un descripteur est qu'il s'agit d'un conduit contrôlé par le noyau du système d'exploitation. Ils ont des numéros uniques (par processus) commençant par 0, qui est généralement le descripteur du flux d' entrée standard .
openat, fstatat, etc.) qui utilisent des descripteurs de fichiers se rapportant à des répertoires.
fsync()un répertoire fd en lecture seule (!), Et il a un effet bien défini (en particulier, il synchronise la création / renommage / suppression de fichiers dans le répertoire donné sur le disque, une étape théoriquement nécessaire dans la "écriture" dans un fichier temporaire et renommez-le sur l'idiome d'origine).
Dans la manière Unix de faire les choses: tout est un fichier.
Un répertoire est un (parmi plusieurs) types de fichiers spéciaux. Il ne contient pas de données. Au lieu de cela, il contient des pointeurs vers tous les fichiers contenus dans le répertoire.
Autres types de fichiers spéciaux:
Mais comme ils sont considérés comme des "fichiers", vous pouvez lsles renommer et les déplacer et, selon le type de fichier spécial, envoyer des données vers / depuis eux.
Ma réponse est une simple réminiscence, mais dans 199x Unixes vintage, dont il y avait beaucoup, les répertoires étaient des fichiers, juste marqués "répertoire" quelque part dans l'inode sur le disque.
Vous pouvez ouvrir un répertoire avec quelque chose comme open(".", O_RDONLY)et récupérer un descripteur de fichier utilisable. Vous pouvez analyser le contenu si vous parcourez /usr/includeet trouvez la bonne définition de structure C. Je sais que je l'ai fait pour les systèmes SunOS 4.1.x, le système de fichiers EFS de SGI et tous les postes de travail Mips-CPU de DEC pour un système de fichiers, probablement BSD4.2 FFS.
Ce fut une mauvaise expérience. La normalisation sur une couche de système de fichiers virtuel est une bonne chose pour la portabilité, même si les répertoires ne sont plus des fichiers stricts. Les couches VFS nous permettent d'expérimenter avec des systèmes de fichiers où les répertoires ne sont pas des fichiers, comme ReiserFS ou NFS.
cp --link dir1/* dir2, bien que je ne sois pas sûr de sa facilité d'utilisation.
Un répertoire est spécial en ce qu'il a le «d» dans son mode, indiquant au système de fichiers qu'il doit interpréter son contenu comme une liste d'autres fichiers contenus dans le répertoire, plutôt que comme un fichier normal qui n'est qu'une séquence d'octets à lu par l'application. C'est tout.
Les répertoires sont des fichiers car les systèmes Linux utilisent un modèle d'E / S universel . Dans le modèle, tout dans le système est un fichier et il est accessible avec les mêmes appels système et diverses commandes.
Ils sont de type spécial parce que leurs i-nœuds ont la marque du type de fichier et ils ont une structure spéciale pour être une table de noms de fichiers et des liens vers d'autres i-nœuds. Ces paires nom de fichier-lien, également appelées "liens physiques", dans le nœud i d'un répertoire énumèrent les fichiers "à l'intérieur" du répertoire.
Les répertoires servent uniquement à organiser les fichiers. Lorsqu'un fichier est «déplacé» d'un répertoire à un autre, le fichier lui-même ne se déplace pas sur le disque. C'est juste qu'une entrée dans un répertoire i-nœuds est supprimée et écrite dans un autre répertoire i-nœuds.
La réponse acceptée n'est pas complètement correcte. dans les systèmes POSIX, les "inodes" pointent vers des fichiers et des répertoires. Les descripteurs de fichiers sont uniquement propres à un processus et non à travers un système. Les inodes sont cependant uniques, bien que plus d'un inode puisse pointer vers un seul fichier. Aurait commenté la réponse acceptée mais n'a pas pu en raison de la restriction des représentants.
ls -l >test.txt;ln -vf test.txt test2.txt;ls -li test.txt test2.txt. Vous verrez donc que les liens matériels ont le même numéro d'inode.
fork()s, son processus enfant aura (sauf certaines circonstances spéciales, à savoir un O_CLOEXECindicateur) exactement les mêmes entités de descripteur de fichier que le processus d'origine. Autre exemple: les processus enfants apache listen()utilisent le même descripteur de fichier socket. Mais cette réponse ne concerne pas les descripteurs de fichiers, qui sont une structure de données interne au noyau et n'existent que dans la mémoire du noyau. Cette ( fausse ) réponse concerne les entrées de répertoire et les inodes, ce sont des entités sur disque (c'est-à-dire que ce sont des octets physiques sur le disque dur).
fork()se produit puis le processus enfant seek()s ou close()s, cela n'affectera pas le descripteur de fichier du parent. Je pense donc maintenant que les descripteurs de fichiers ne sont que partiellement des structures privées de processus. Mais cette question ne les concerne pas, cette question concerne les dirents / inodes et je vous commente une réponse entièrement fausse à cette question.