Pourquoi stocker les liens auto et parent (. Et ..) dans une entrée de répertoire?

11

Prenons un système de fichiers ciblé sur certains périphériques intégrés qui ne fait guère plus que de stocker des fichiers dans une structure de répertoires hiérarchique. Ce système de fichiers manque de nombreuses opérations auxquelles vous pouvez être habitué dans des systèmes tels qu'Unix et Windows (par exemple, ses autorisations d'accès sont complètement différentes et non liées aux métadonnées stockées dans des répertoires). Ce système de fichiers n'autorise aucun type de lien dur ou de lien logiciel, donc chaque fichier a un nom unique dans une arborescence stricte.

Y a-t-il un avantage à stocker un lien vers le répertoire lui-même et vers son parent dans la structure de données sur disque qui représente un répertoire?

La plupart des systèmes de fichiers Unix ont .et des ..entrées sur le disque. Je me demande pourquoi ils ne gèrent pas ceux de la couche VFS (pilote de système de fichiers générique). Est-ce un artefact historique? Y a-t-il une bonne raison, et si oui, laquelle précisément, afin que je puisse déterminer si elle est pertinente pour mon système embarqué?

operating-systems filesystems

— Gilles 'SO- arrête d'être méchant'
source

J'ai toujours pensé qu'ils n'étaient là que virtuellement pour que les programmes puissent facilement accéder au répertoire courant et parent. Question intéressante, mais appartient-elle ici?

— Raphael

@Raphael Je pourrais comprendre si vous considérez ma question trop large (→ «pas une vraie question»), ou peut-être «pas constructive», car elle est quelque peu ouverte. Mais je ne suis pas d'accord pour dire que c'est hors sujet: il s'agit de la conception d'un système de fichiers, comment cela n'est-il pas appliqué à l'informatique? Si vous pensez que c'est hors sujet, veuillez expliquer votre raisonnement sur la méta.

— Gilles 'SO- arrête d'être méchant'

@Raphael J'ai édité ma question, j'espère qu'il devrait être clair que mon point de vue est celui d'un concepteur de système d'exploitation intégré. Merci pour vos commentaires.

— Gilles 'SO- arrête d'être méchant'

2

Avoir des liens vers le répertoire parent me semble logique. Si vous ne les aviez pas, vous auriez toujours besoin de travailler avec toute une liste de répertoires. Ainsi, par exemple, /home/svick/Documents/devrait être représenté par { /, /home/, /home/svick/, /home/svick/Documents }. Si vous ne le faisiez pas, vous ne seriez pas en mesure de trouver le répertoire parent du tout (ou ce serait très cher). Ce n'est pas seulement inefficace, mais aussi dangereux. Si vous avez deux de ces listes qui se chevauchent, elles pourraient facilement se désynchroniser si vous déplaciez un répertoire.

D'un autre côté, si vous avez une référence au répertoire parent, c'est plus efficace et plus sûr.

Je ne vois aucune raison d'avoir réellement un lien vers le répertoire courant. Si vous avez une structure qui représente un répertoire et que vous souhaitez accéder à ce répertoire, son utilisation .est toujours totalement inutile. Pour cette raison, je m'attendrais à ce que le .lien n'existe pas réellement dans la structure du système de fichiers et soit uniquement virtuel.

— svick
source

2

Même remarque: pourquoi le faire dans chaque système de fichiers plutôt que dans la couche VFS? La plupart des systèmes de fichiers Linux ont des entrées .et des ..entrées.

— Gilles 'SO- arrête d'être méchant'

Comme je l'ai dit, je pense que c'est plus efficace. Vous pouvez travailler uniquement avec le répertoire actuel et accéder à ses parents uniquement lorsque vous en avez besoin. Si vous n'aviez pas de liens parents, vous devrez toujours conserver tous les répertoires du chemin complet de root en mémoire. Et vous en aurez besoin pour chaque entrée que vous utilisez.

— svick

1

@svick: Gilles ne compare pas avoir des liens parents avec ne pas avoir de liens parents. Il compare les avoir dans le système de fichiers réel avec les faire simuler par une couche intermédiaire de code (vfs) entre le système de fichiers réel et l'espace utilisateur.

— rgrig

2

Vous obtenez moins de cas spéciaux. Dans de nombreuses situations, VFS peut gérer ".." comme il gère tout autre nom de répertoire.

— rgrig
source

3

Si les répertoires sont virtuels, le programme (mode utilisateur je présume) peut toujours le gérer comme n'importe quel autre répertoire. Vous n'avez pas vraiment besoin des liens à présenter au niveau du stockage.

— Aryabhata

1

Oui, mais pourquoi ne pas gérer cela au niveau de la couche VFS? Pourquoi y aurait-il un stockage associé?

— Gilles 'SO- arrête d'être méchant'

Pourquoi les gens implémentent-ils des listes liées avec une sentinelle au lieu de prendre soin du cas de liste vide dans les fonctions d'ajout / suppression?

— rgrig

@rgrig: Cela ne se produit que lorsque l'interface avec l'implémentation de la liste chaînée considérée est écrite dans un langage exceptionnellement mauvais pour gérer les structures de données inductives (C, Java, etc…). Ici, ce problème n'est pas pertinent car la couche VFS n'est pas directement accessible d'un point de vue utilisateur.

— Stéphane Gimenez

@ StéphaneGimenez: Ce problème est pertinent, car VFS est écrit en C.

— rgrig

2

La seule raison pour laquelle je peux imaginer est le scénario suivant:

Une implémentation originale d'un système de fichiers existait avec le même format de répertoire mais les notions de chemins de fichiers et de sous-répertoires n'étaient pas envisagées à l'époque (Voir Le système de fichiers Unix PDP-7 ).
Ensuite, les gens ont pensé que la résolution des chemins et les sous-répertoires seraient utiles!
Pour conserver une certaine compatibilité descendante avec les anciennes implémentations, il a été décidé que le .et ..sera stocké sur le disque comme tout autre répertoire.

Alors peut-être que nous nous retrouvons avec ces artefacts inutiles, juste pour des raisons de rétrocompatibilité avec des logiciels vieux de 40 ans? Scénario crédible?

Remarque: il n'était pas complètement stupide d'ajouter ces entrées à la liste des répertoires, car vous devez de toute façon stocker le numéro d'inode de votre véritable répertoire parent (rappelez-vous que les liens physiques sur les répertoires étaient autorisés à ce moment), et une référence à votre son propre numéro d'inode peut être un bon test de santé mentale.

— Stéphane Gimenez
source

1

Je ne vois pas de raison de l'implémenter .et ..à l'un ou l'autre niveau plutôt qu'à l'autre. Cependant, si vous ciblez des systèmes embarqués, n'importe quelle couche que vous pouvez économiser peut rapporter de l'argent, il peut donc être judicieux de tout mettre en œuvre le plus bas possible.

Quant au besoin général de .et .., comment exprimeriez-vous des chemins relatifs sans eux? Au moins ..est indispensable pour les chemins qui quittent le sous-arbre actuel. Si vous n'avez pas besoin de tels chemins (peut-être que l'arborescence est un moyen primitif de coder les privilèges d'accès?), Vous n'en avez pas besoin ...

— Raphael
source