En quoi un répertoire est-il un «type de fichier spécial»?

Réponses:

19

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 .

boucle d'or
la source
2
POSIX.1-2008 a ajouté un tas d'appels système ( openat, fstatat, etc.) qui utilisent des descripteurs de fichiers se rapportant à des répertoires.
zwol
2
Encore plus intéressant, vous pouvez 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).
Kevin
13

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:

  • liens
  • douilles
  • dispositifs

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.

hymie
la source
1
Et cela rend la vie beaucoup plus facile, car vous n'avez pas à faire quelque chose de différent simplement parce que c'est un répertoire. Cela s'applique à l'écriture de programmes ainsi qu'aux opérations à partir de la ligne de commande (ou GUI).
gbarry
1
Un répertoire contient des données: les données qui décrivent les fichiers contenus dans le répertoire. Il est parfaitement possible d'accéder à un répertoire (mais peut-être pas avec un appel ouvert standard) et de lire ces données vous-même, bien que (comme Bruce Ediger le note dans sa réponse), les données ne sont pas très utiles à moins que vous ne connaissiez le format.
jamesqf
11

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.

Bruce Ediger
la source
1
Connexes: Comment inspecter les informations de structure de répertoire d'un fichier Unix / Linux? et Quand les répertoires ont-ils cessé d'être lisibles en tant que fichiers?
Scott
1
Vous pouvez toujours ouvrir un répertoire et le lire sous forme de fichier sur certaines variantes Unix aujourd'hui, par exemple c'est toujours possible sur FreeBSD 10.1. (Peut ≠ devrait)
Gilles 'SO- arrête d'être méchant'
@Gilles Je pense qu'il serait très logique qu'un répertoire copié par dd soit essentiellement un équivalent de cp --link dir1/* dir2, bien que je ne sois pas sûr de sa facilité d'utilisation.
Peterh dit de réintégrer Monica le
3

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.

psusi
la source
Les choses ne sont pas si simples avec tous les systèmes de fichiers - par exemple, dans le HFS + d'Apple, il n'y a qu'un seul grand arbre B + contenant tous les noms de chemin, si je me souviens bien - mais cette observation est exacte pour les systèmes de fichiers Unix jusqu'à et y compris les ffs de BSD, qui est probablement ce à quoi pensaient les auteurs du tutoriel cité.
zwol
2

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.

Henri Kynsilehto
la source
-3

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.

meule
la source
2
Non, seul 1 inode peut pointer vers le même fichier. Bien que le même inode puisse exister simultanément dans plusieurs répertoires (ou sur plusieurs noms). Un contrôle facile: 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.
peterh dit réintégrer Monica le
@peterh Les descripteurs de fichiers ne sont uniques qu'à un processus. peux-tu expliquer?
alamin
1
@ Md.AlaminMahamud Ce n'est pas vrai, si un processus 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).
Peterh dit de réintégrer Monica le
1
@ Md.AlaminMahamud Eh bien, maintenant je ne suis pas très sûr, par exemple si un événement 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.
peterh dit réintégrer Monica le