Pourquoi les liens physiques vers des répertoires ne sont-ils pas autorisés sous UNIX / Linux?

Cest juste une mauvaise idée, car là nest aucun moyen de faire la différence entre un lien physique et un nom original.

Autoriser les liens physiques vers les répertoires briserait la structure du graphe acyclique dirigé du système de fichiers, créant éventuellement des boucles de répertoires et des sous-arborescences rendre fsck et tout autre explorateur darborescence de fichiers sujet aux erreurs.

Premièrement, pour comprendre cela, parlons des inodes. Les données du système de fichiers sont conservées dans blocs sur le disque, et ces blocs sont rassemblés par un inode. Vous pouvez considérer l’inode comme LE fichier. Les inodes manquent de nom de fichier, cependant. Cest là que les liens entrent en jeu.

Un lien est juste un pointeur vers un inode. Un répertoire est un inode contenant des liens. Chaque nom de fichier dans un répertoire nest quun lien vers un inode. Louverture dun fichier sous Unix crée également un lien, mais cest un type de lien différent (ce nest pas un lien nommé).

Un lien physique est juste une entrée de répertoire supplémentaire pointant vers cet inode. Lorsque vous ls -l, le nombre après les autorisations est le nombre de liens nommé. La plupart des fichiers réguliers auront un lien. La création dun nouveau lien physique vers un fichier fera pointer les deux noms de fichiers vers le même inode. Remarque:

% ls -l test ls: test: No such file or directory % touch test % ls -l test -rw-r--r-- 1 danny staff 0 Oct 13 17:58 test % ln test test2 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 % touch test3 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 ^ ^ this is the link count 

Maintenant, vous pouvez clairement voir quil nexiste pas de lien physique. Un lien physique est identique à un nom normal. Dans lexemple ci-dessus, test ou test2, quel est le fichier dorigine et quel est le lien physique? À la fin, vous ne pouvez pas vraiment dire (même par horodatage) car les deux noms pointent vers le même contenu, le même inode:

% ls -li test* 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 14445892 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 

Le -i drapeau à ls affiche les numéros dinode au début de la ligne. Notez comment test et test2 ont le même numéro dinode, mais test3 en a un autre.

Maintenant, si vous étiez autorisé à faites cela pour les répertoires, deux répertoires différents situés à des points différents du système de fichiers pourraient pointer vers la même chose. En fait, un sous-répertoire pourrait pointer vers son grand-parent, créant une boucle.

Pourquoi cette boucle est-elle un problème ? Parce que lorsque vous parcourez, il ny a aucun moyen de détecter que vous faites une boucle (sans garder une trace des numéros dinode pendant que vous traversez). Imaginez que vous écrivez la commande du, qui doit parcourir les sous-répertoires pour en savoir plus sur lutilisation du disque. Comment du saurait-il où n il a frappé une boucle? Cest sujet aux erreurs et à beaucoup de comptabilité que du devrait faire, juste pour accomplir cette tâche simple.

Les liens symboliques sont une toute autre bête, en quil sagit dun type spécial de «fichier» que de nombreuses API de système de fichiers de fichiers ont tendance à suivre automatiquement. Notez quun lien symbolique peut pointer vers une destination inexistante, car il pointe par son nom et non directement vers un inode. Ce concept na pas de sens avec les liens physiques, car la simple existence dun « lien physique » signifie que le fichier existe.

Alors pourquoi du peut-il traiter les liens symboliques facilement et non les liens physiques? Nous avons pu voir ci-dessus que les liens physiques ne se distinguent pas des entrées normales du répertoire. Cependant, les liens symboliques sont spéciaux, détectables et désactivables! du remarque que le Le lien symbolique est un lien symbolique et lignore complètement!

% ls -l total 4 drwxr-xr-x 3 danny staff 102 Oct 13 18:14 test1/ lrwxr-xr-x 1 danny staff 5 Oct 13 18:13 test2@ -> test1 % du -ah 242M ./test1/bigfile 242M ./test1 4.0K ./test2 242M . 

Commentaires

• Allowing hard links to directories would break the directed acyclic graph structure of the filesystem.Pouvez-vous expliquer plus en détail le problème des cycles utilisant des liens physiques? Pourquoi les liens symboliques sont-ils acceptés?
• Ils semblent lavoir autorisé sur les Mac en ajoutant une détection de cycle à lappel système link () et en refusant de vous permettre de créer un lien direct vers un répertoire si cela créait un cycle . Semble être une solution raisonnable.
• @psusi mkdir -p a / b; nocheckln c a; mv c a / b; – le nocheckln il y a un ln théorique qui ne vérifie pas les arguments de répertoire, et passe juste au lien, et comme aucun cycle nest fait, nous sommes tous bons pour créer ‘ c ‘. puis nous déplaçons ‘ c ‘ dans ‘ a / b ‘, et un cycle est créé à partir de a / b / c – > a / – lenregistrement de link () nest pas suffisant
• Les cycles sont très mauvais. Windows a ce problème avec les  » jonctions  » qui sont des répertoires de liens en dur. Si vous appliquez accidentellement des autorisations à lensemble de votre profil, cela découvre une série de jonctions qui créent un cycle infini. La récurrence dans les répertoires se répète jusquà ce que les limitations de longueur de chemin larrêtent.
• @WhiteWinterWolf, selon ce lien, ils ont spécifiquement ajouté le support pour Time Machine, mais seul root est autorisé à le faire: superuser.com/questions/360926/…

Vous pouvez utiliser bind mount pour simuler des répertoires de liens fixes

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory sudo umount /else/dummy_but_existing_directory 

À lexception des points de montage, chaque répertoire a un seul et unique parent: ...

Une façon de do pwd est de vérifier le périphérique: inode pour « . » et « .. ». Sils sont identiques, vous avez atteint la racine du système de fichiers. Sinon, trouvez le nom du répertoire courant dans le parent, poussez-le sur une pile et commencez à comparer « ../ ». avec « ../ .. », puis « ../../. » avec « ../../ .. », etc. Une fois que vous avez atteint la racine, commencez à afficher et à imprimer les noms de la pile. Cet algorithme repose sur le fait que chaque répertoire a un et un seul parent.

Si les liens physiques vers les répertoires étaient autorisés, lequel des multiples parents devrait .. pointer? Cest une raison impérieuse pour laquelle les liens physiques vers des répertoires ne sont pas autorisés.

Les liens symboliques vers des répertoires ne causent pas ce problème. Si un programme le souhaite, il peut faire un lstat() sur chaque partie du chemin et détecter quand un lien symbolique est rencontré. Lalgorithme pwd retournera le vrai chemin absolu dun répertoire cible. Le fait quil y ait un morceau de texte quelque part (le lien symbolique) qui pointe vers le répertoire cible est à peu près hors de propos. Lexistence dun tel lien symbolique ne crée pas de boucle dans le graphe.

Commentaires

• Pas si sûr à ce sujet. Si nous considérons .. comme une sorte de lien physique virtuel vers le parent, il ny a aucune raison technique pour que la cible du lien ne puisse avoir quun seul autre lien vers celui-ci. pwd devrait simplement utiliser un algorithme différent pour résoudre le chemin.

Jaime ajouter quelques points supplémentaires sur cette question. Les liens physiques pour les répertoires sont autorisés sous Linux, mais de manière restreinte.

Une façon de tester cela est lorsque nous listons le contenu dun répertoire, nous trouvons deux répertoires spéciaux « . » et « .. ». Comme nous le savons « . » pointe vers le même répertoire et « .. » pointe vers le répertoire parent.

Créons donc une arborescence de répertoires où « a » est le répertoire parent qui a le répertoire « b » comme enfant.

 a `-- b 

Notez linode du répertoire « a ». Et quand nous faisons un ls -la à partir du répertoire « a », nous pouvons voir cela « . » Le répertoire pointe également vers le même inode.

797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 a 

Et ici, nous pouvons trouver que le répertoire « a » a trois liens durs. Cela est dû au fait que linode 797358 a trois liens physiques au nom de « . » à lintérieur du répertoire « a » et le nom comme « .. » à lintérieur du répertoire « b » et un avec le nom « a » itslef.

$ ls -ali a/ 797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 . $ ls -ali a/b/ 797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 .. 

Nous pouvons donc comprendre ici que les liens physiques sont là pour les répertoires uniquement pour se connecter à leurs répertoires parent et enfant. Et donc un répertoire sans enfant naura que 2 liens physiques, et donc le répertoire « b » naura que deux liens physiques.

Une des raisons pour lesquelles les liens physiques de répertoires librement ont été empêchés serait déviter des boucles de référence infinies qui confondra les programmes qui traversent le système de fichiers.

Comme le système de fichiers est organisé sous forme darborescence et que larbre ne peut pas avoir de référence cyclique, cela aurait dû être évité.

Commentaires

• Bon exemple. Cela a dissipé mon doute. Ainsi, ces cas sont traités de manière spéciale pour éviter des boucles infinies. droit?
• Comme nous avons un moyen limité dautoriser les liens physiques pour les répertoires, cest-à-dire  » ..  » et « .  » nous natteindrons pas une boucle infinie et nous naurions donc pas besoin de moyens spéciaux pour les éviter car ils ne se produiront pas 🙂

Aucune des raisons suivantes nest la vraie raison pour interdire les liens physiques vers des répertoires; chaque problème est assez simple à résoudre:

• les cycles dans larborescence entraînent un parcours difficile
• plusieurs parents, alors quel est le « vrai »?
• garbage collection du système de fichiers

La raison réelle (comme indiqué par @ Thorbjørn Ravn Andersen) intervient lorsque vous supprimez un répertoire qui a plusieurs parents, à partir du répertoire pointé par ..:

Sur quoi .. doit-il maintenant pointer?

Si le répertoire est supprimé de son parent mais que son nombre de liens est toujours supérieur à 0 alors il doit y avoir quelque chose, quelque part qui pointe toujours dessus. Vous ne pouvez « t laisser .. pointer vers rien; de nombreux programmes reposent sur .., le système devrait donc traverser le tout le système de fichiers jusquà ce quil trouve la première chose qui pointe vers le répertoire supprimé, juste pour mettre à jour ... Soit cela, soit le système de fichiers devrait maintenir une liste de tous les répertoires pointant vers un répertoire lié en dur.

Dans tous les cas, cela entraînerait une surcharge de et une complication supplémentaire pour les métadonnées et / ou le code du système de fichiers, les concepteurs ont donc décidé de ne pas lautoriser.

Commentaires

• Que ‘ est également facile à résoudre: gardez une liste des parents dun répertoire enfant, que vous mettez à jour lorsque vous ajoutez ou supprimez un lien vers lenfant. Lorsque vous supprimez le parent canonique (la cible de lenfant ‘ s

  ), mettez à jour .. pour pointer vers lun des autres parents de la liste.

• Je suis daccord. Pas sorcier à résoudre. Mais néanmoins, une surcharge de performances, et cela prendrait un peu plus despace dans les métadonnées du système de fichiers et ajouterait une complication. Et donc les concepteurs ont opté pour une approche simple et rapide – ne ‘ t autoriser les liens vers des répertoires matériels.
• Liens Sym vers des répertoires  » violer la sémantique et les comportements établis « , mais ils sont toujours autorisés. Certaines commandes ont donc besoin doptions pour contrôler si les liens sym sont suivis (par exemple -L dans find et cp). Lorsquun programme suit ‘ .. ‘, il y a davantage de confusion, doù la différence de sortie de pwd et / bin / pwd après avoir parcouru un lien sym. Il ny a pas de  » réponses Unix « ; juste des décisions de conception. Celui-ci tourne autour de ce que devient  » ..  » comme je lai dit dans ma réponse. Malheureusement, ‘ .. ‘ nest même pas ‘ mentionné dans la réponse que tout le monde vote si timidement pour.
• BTW, je ‘ je ne dis pas que je ‘ je suis en faveur des liens physiques aux dirs. Pas du tout. Je ‘ ne veux pas que mon travail quotidien soit plus difficile qu’il ne l’est déjà.
• Ce ‘ n’est pas quoi POSIX dit, mais IMO ‘ .. ‘ naurait jamais dû être un concept de système de fichiers, plutôt résolu syntaxiquement sur les chemins, de sorte que a/.. signifierait toujours .. Cest ainsi que fonctionnent les URL, btw. ‘ est le navigateur qui ‘ résout ‘ .. ‘ avant même quil natteigne le serveur. Et cela fonctionne très bien.

La création de liens physiques sur des répertoires serait irréversible. Supposons que nous ayons:

/dir1 ├──this.txt ├──directory │ └──subfiles └──etc 

Je le lie en dur à /dir2.

Donc /dir2 contient désormais aussi tous ces fichiers et répertoires

Et si je change davis? Je peux « t juste rmdir /dir2 (car il nest pas vide)

Et si je supprime récursivement dans /dir2. .. il sera également supprimé de /dir1!

À mon humble avis, cest une raison largement suffisante pour éviter cela!

Modifier:

Les commentaires suggèrent de supprimer le répertoire en faisant rm dessus .Mais rm sur un répertoire non vide échoue, et ce comportement doit rester, que le répertoire soit lié en dur ou non. Vous pouvez donc « t simplement rm pour le dissocier. Cela nécessiterait un nouvel argument pour rm, juste pour dire » si le répertoire inode a un nombre de références> 1, alors seulement dissocier le répertoire « .

Ce qui, à son tour, rompt un autre principe de moindre surprise: cela signifie que la suppression dun répertoire hardlink que je viens de créer nest pas la même chose que la suppression dun fichier normal hardlink …

Je reformulerai ma phrase: Sans développement supplémentaire, la création de hardlink serait irréversible (car aucune commande actuelle ne pourrait gérer la suppression sans être incohérente avec le comportement actuel)

Si nous permettons à davantage de développement de gérer le cas, le nombre de pièges et le risque de perte de données si vous « ne sont pas assez conscients de la façon dont le système fonctionne, un tel développement implique, est IMHO une raison suffisante pour restreindre les liens en dur sur les répertoires.

Commentaires

• Cela ne devrait pas être un problème. Dans votre cas, lorsque nous créons un lien direct vers dir2, nous devons créer un lien direct vers tout le contenu de dir1 et donc si nous renommons ou supprimons dir2, seul un lien supplémentaire vers linode est supprimé. Et cela ne devrait pas affecter dir1 et son contenu car il y a au moins un lien (dir1) vers linode.
• Votre argument est incorrect. Vous voudriez simplement le dissocier, pas faire rm -rf. Et si le nombre de liens atteint 0, le système saurait quil peut également supprimer tout le contenu.
• Ce ‘ est plus ou moins tout rm fait quand même en dessous (dissociation). Voir: unix.stackexchange.com/questions/151951/… Ceci nest vraiment pas ‘ t un problème, pas plus quavec les fichiers liés en dur. La dissociation supprime simplement la référence nommée et décrémente le nombre de liens. Le fait que rmdir na pas ‘ supprimer les répertoires non vides na pas dimportance – cela ne ‘ Faites cela pour dir1 non plus. Les liens physiques ne sont ‘ que des copies de données, ce sont le même fichier réel, doù la  » suppression  » le fichier dir2 effacerait la liste des répertoires pour dir1. Vous devrez toujours dissocier.
• Vous pouvez ‘ simplement le dissocier comme un fichier normal, car rm sur un répertoire don ‘ t dissociez-le sil ‘ nest pas vide. Voir Modifier.

Cest une bonne explication. Concernant « Lequel des parents multiples devrait … pointer? » une solution serait pour un processus de conserver son chemin wd complet, soit sous forme dinœuds, soit sous forme de chaîne. les inodes seraient plus robustes puisque les noms peuvent être modifiés. Au moins dans les temps anciens, il y avait un inode interne pour chaque fichier ouvert qui était incrémenté chaque fois quun fichier était ouvert, décrémenté lorsquil était fermé. Lorsquil atteignait zéro, le stockage quil désignait serait libéré. Lorsque le fichier nétait plus ouvert par personne, il (la copie interne) était abandonné. Cela maintiendrait le chemin comme valide si un autre processus déplaçait un répertoire vers un autre répertoire alors que le sous-répertoire était dans le chemin dun autre processus. Similaire à la façon dont vous pouvez supprimer un fichier ouvert, mais il est simplement supprimé du répertoire, mais reste ouvert pour tous les processus qui lont ouvert.

Les répertoires de liaison en dur étaient auparavant autorisés dans Bell Labs UNIX, au moins V6 et V7, Je ne sais pas pour Berkeley ou plus tard. Aucun drapeau requis. Pourriez-vous faire des boucles? Oui, ne le faites pas. Ce que vous faites est très clair si vous faites une boucle. Ne devriez-vous pas vous entraîner à nouer autour de votre cou pendant que vous attendez votre tour de sauter dun avion si vous avez lautre extrémité accrochée à un crochet sur la tête en vrac.

Quoi Jespérais faire avec cela aujourdhui était de relier en dur lhome à la maison afin que je puisse avoir / home / administ disponible, que / home soit ou non couvert par un automout sur home, cet automount ayant un lien symbolique nommé administ vers / lhome / administ. Cela me permet davoir un compte administratif qui fonctionne quel que soit létat de mon système de fichiers principal. Ceci EST une expérience pour Linux, mais je pense que jai appris à un moment donné pour le SunOS basé sur UCB que les montages automatiques sont effectués au niveau de la chaîne ascii. Il est difficile de voir comment ils pourraient être faits autrement comme une couche au-dessus de tout FS arbitraire.

Jai lu ailleurs cela. et .. ne sont plus des fichiers dans le répertoire non plus. Je suis sûr quil y a de bonnes raisons à tout cela, et quune grande partie de ce que nous apprécions (comme pouvoir monter NTFS) est possible grâce à de telles choses, mais une partie de lélégance dUNIX résidait dans limplémentation.Ce sont les avantages tels que la généralité et la malléabilité que cette élégance a apportés qui lui ont permis dêtre si robuste et de durer quatre décennies. Comme nous perdons les implémentations élégantes, il deviendra finalement comme Windows (jespère que je me trompe!). Quelquun créerait alors un nouveau système dexploitation basé sur des principes élégants. Quelque chose à quoi penser. Peut-être que je me trompe, je ne suis pas (évidemment) familier avec la mise en œuvre actuelle. Cest étonnant de voir à quel point une compréhension vieille de 30 ans est applicable à Linux … la plupart du temps!

Commentaires

• Je pense, bien que je puisse me tromper, que . et .. ne sont pas des liens physiques dans le système de fichiers, pour les systèmes de fichiers modernes. Cependant, le pilote du système de fichiers les simule. Ce sont ces systèmes de fichiers qui empêchent les répertoires de liaison fixe. Pour les anciens systèmes de fichiers, cétait possible (mais dangereux). Pour faire ce que vous essayez, regardez mount --bind, voir aussi mount --make… et peut-être les conteneurs.

Daprès ce que je comprends, la raison principale est quil est utile de pouvoir changer les noms de répertoire sans gâcher les programmes en cours qui utilisent leur répertoire de travail pour référencer dautres fichiers. Supposons que vous utilisiez Wine pour exécuter ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe et que vous vouliez déplacer le préfixe entier vers ~/.wine à la place. Si, pour une raison étrange, Firefox accédait à drive_c/windows en se référant à ../../windows, renommer ~/.newwineprefix sarrête implémentations de .. qui gardent une trace du répertoire parent sous forme de chaîne de texte au lieu dun inode.

Le stockage de linode dun seul répertoire parent doit être plus simple que dessayer pour garder une trace de chaque chemin à la fois comme une chaîne de texte et une série dinœuds.

Une autre raison est que le mauvais comportement ng applications peuvent être capables de créer des boucles. Les applications qui se comportent devraient être en mesure de vérifier si l’inode du répertoire qui est déplacé est le même que l’inode de l’un des répertoires imbriqués dans lequel il est déplacé, tout comme vous ne pouvez pas déplacer un répertoire vers lui-même, mais cela peut ne pas être appliqué au niveau du système de fichiers.

Une autre raison pourrait être que si vous pouviez créer des liens en dur dans les répertoires, vous voudriez empêcher la liaison en dur dun répertoire que vous ne pourriez pas modifier. find a des considérations de sécurité car il est utilisé pour effacer les fichiers créés par d’autres utilisateurs à partir de répertoires temporaires, ce qui peut causer des problèmes si un utilisateur change de répertoire réel pour un lien symbolique alors que find appelle une autre commande. Pouvoir relier en dur des répertoires importants obligerait un administrateur à ajouter des tests supplémentaires à find pour éviter de les affecter. (Ok, vous avez déjà ne peut pas faire cela pour les fichiers, donc cette raison n’est pas valide.)

Une autre raison est que le stockage de l’inode du répertoire parent peut fournir une redondance supplémentaire en cas de corruption ou d’endommagement du système de fichiers. voulait que .. répertorie tous les répertoires parents qui sont liés en dur à celui-ci, donc un parent différent et arbitraire pourrait être facilement trouvé si le parent actuel est dissocié, non seulement vous violez lidée que durement les liens sont égaux, vous devez modifier la façon dont le système de fichiers stocke et utilise les inodes. Faire en sorte que les programmes traitent les chemins comme une série (uniq ue à chaque lien dur) des inodes de répertoire éviterait cela, mais vous nobtiendrez pas la redondance en cas de dommage du système de fichiers.