Question Pourquoi les liens durs ne sont-ils pas autorisés pour les répertoires?


J'utilise Ubuntu 12.04. Lorsque j'essaie de créer un lien dur pour un répertoire, il échoue. Je peux créer des liens durs pour les fichiers à l'intérieur des limites du système de fichiers. Je connais la raison pour laquelle nous ne pouvons pas créer de liens durs pour les fichiers au-delà du système de fichiers.

J'ai essayé ces commandes:

$ ln /Some/Direcoty /home/nischay/Hard-Directory
hard link not allowed for directory
$ sudo ln /Some/Direcoty /home/nischay/Hard-Directory
[sudo] password for nischay: 
hard link not allowed for directory

Je veux juste savoir la raison derrière cela. Est-ce la même chose pour toutes les distributions GNU / Linux et les versions Unix (BSD, Solaris, HP-UX, IBM AIX) ou seulement sous Ubuntu ou Linux?


97
2017-11-01 21:18


origine


unix.stackexchange.com/questions/22394/… - Nanne
Essayer ln -F <src> <dst> et cela pourrait travail. Certes, il fonctionnait pour le super-utilisateur dans les anciennes versions d'Unix. Est-ce que quelqu'un se souvient si c'était UCB ou System V? Oui, de mauvaises choses pourraient arriver, mais généralement pas. Si je me souviens bien, rmdir savait ne pas continuer à supprimer un lien dur. Cependant, les utilisateurs peuvent être déroutés et supprimer des éléments erronés. - Steve Pitchers
@StevePitchers Comment peut-on rmdir gérer les liens durs d'une manière particulière? Un lien physique est juste un lien normal - mais un lien supplémentaire. Il n'est même pas facile de savoir si des liens supplémentaires inhabituels existent sans enregistrements supplémentaires. - Volker Siegel
Chaque nœud stocke le nombre de liens physiques qui le pointent: le contenu n'est publié qu'une fois qu'il ne reste plus de liens. Alors rmdir peut dire si le répertoire a des liens d'autres endroits. Retrait récursif, rm -r, doit être codé avec soin, pour s’assurer qu’il agira correctement même s’il ya des erreurs comme "permission refusée". BTW, UCB = BSD, doh! - Steve Pitchers
j'ai fait ln -F sur les répertoires et le faire fonctionner. Mais vous ne devez pas supprimer le répertoire par la suite de peur de corrompre le système de fichiers. - Edward Falk


Réponses:


Les liens matériels des répertoires cassent le système de fichiers de plusieurs manières

Ils vous permettent de créer des boucles

Un lien physique vers un répertoire peut être lié à un parent lui-même, ce qui crée une boucle de système de fichiers. Par exemple, ces commandes pourraient créer une boucle avec le lien arrière l:

mkdir -p /tmp/a/b
cd /tmp/a/b
ln -d /tmp/a l

Un système de fichiers avec une boucle de répertoire a une profondeur infinie:

cd /tmp/a/b/l/b/l/b/l/b/l/b

Tout find commande sans le -maxdepth le prédicat sera exécuté dans une boucle infinie. Cela signifie que vous ne pouvez plus utiliser find, qui est une commande importante, de manière cohérente. Similaire pour le même important locate commander.

Un arbre, par définition, n'a pas de boucle, le système de fichiers n'est donc plus un arbre.

Ils brisent la non-ambiguïté des répertoires parents

Avec une boucle de système de fichiers, plusieurs répertoires parent existent:

cd /tmp/a/b
cd /tmp/a/b/l/b

Dans le premier cas, /tmp/a est le répertoire parent de /tmp/a/b.
Dans le second cas, /tmp/a/b/l est le répertoire parent de /tmp/a/b/l/b, qui est la même que /tmp/a/b.
Donc, il a deux répertoires parents.

Ils multiplient les fichiers

Les fichiers sont identifiés par des chemins, après résolution des liens symboliques. Alors

/tmp/a/b/foo.txt
/tmp/a/b/l/b/foo.txt

sont des fichiers différents.
Il existe une infinité d'autres chemins du fichier. Ils sont les mêmes en termes de nombre d'inodes bien sûr. Mais si vous ne vous attendez pas explicitement à des boucles, il n'y a aucune raison de vérifier cela.

Un répertoire hardlink peut également pointer vers un répertoire enfant ou un répertoire qui n'est ni enfant ni parent de quelque profondeur que ce soit. Dans ce cas, un fichier enfant du lien serait répliqué sur deux fichiers, identifiés par deux chemins.

Votre exemple

$ ln /Some/Direcoty /home/nischay/Hard-Directory
$ echo foo > /home/nischay/Hard-Directory/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ echo bar >> /Some/Direcoty/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ cat /Some/Direcoty/foobar.txt
foo
bar

Comment les liens logiciels vers les répertoires peuvent-ils alors fonctionner?

Un chemin qui peut contenir des liens hypertexte et même des boucles de répertoires en liaison douce est souvent utilisé uniquement pour identifier et ouvrir un fichier. Il peut être utilisé comme un chemin linéaire normal.

Mais il existe d'autres situations, lorsque des chemins sont utilisés pour comparer des fichiers. Dans ce cas, les liens symboliques dans le chemin peuvent être résolus en premier, le convertissant en un minimal, et communément convenu sur la représentation créant un chemin canonique:

C'est possible, car les liens logiciels peuvent tous être étendus à des chemins sans lien. Après avoir fait cela avec tous les liens logiciels dans un chemin, le chemin restant fait partie d'un arbre, où un chemin est toujours sans ambiguïté.

La commande readlink peut résoudre un chemin vers son chemin canonique:

$ readlink -f /some/symlinked/path

Les liens logiciels sont différents de ce que le système de fichiers utilise

Un lien logiciel ne peut pas causer tous les problèmes car il est différent des liens à l'intérieur du système de fichiers. Il peut être distingué des liens durs, et résolu en un chemin sans liens symboliques si nécessaire.
Dans un certain sens, l'ajout de liens symboliques ne modifie pas la structure de base du système de fichiers - il le conserve, mais ajoute davantage de structure comme une couche d'application.


De man readlink:

 NAME
        readlink - print resolved symbolic links or canonical
        file names

 SYNOPSIS
        readlink [OPTION]... FILE...

 DESCRIPTION
        Print value of a symbolic link or canonical file name

        -f, --canonicalize
               canonicalize by  following  every  symlink  in
               every component of the given name recursively;
               all but the last component must exist
        [  ...  ]

124
2017-09-17 11:06



+1 Meilleure réponse IMO. La réponse acceptée parle des avantages / inconvénients des liens symboliques par rapport aux liens directs, mais ne répond pas réellement à la question initiale. J'ai été étonné que personne n'ait mentionné la raison du fait que vous ne pouvez pas créer de liens vers des répertoires, jusqu'à ce que je sois enfin arrivé à ce poste;) - Malte Skoruppa
Pourquoi un lien logiciel ne peut-il pas faire tout cela? - Tanay
@ Tanay Right, cela pourrait aider l’expansion à le comparer à des cas similaires avec des liens mous. J'essaierai. - Volker Siegel
Comment cela concerne-t-il uniquement les répertoires? La façon dont je le comprends, ces problèmes sont également un problème pour les fichiers liés par un lien dur. De plus, je considère le hardlinking comme un moyen facile de modifier les autorisations d'un répertoire donné pour autoriser d'autres personnes à l'intérieur, sans avoir à les autoriser à l'intérieur de la chaîne parente. Des sons très utile si vous n'avez pas la possibilité d'ajouter / modifier des groupes ... - inetknght
bonne réponse, mais alors ... comment Apple a-t-il résolu ces problèmes pour Time Machine? - Damien


"En général, vous ne devriez pas utiliser de liens physiques" est trop large. Vous devez comprendre la différence entre les liens physiques et les liens symboliques, et les utiliser comme il convient. Chacun a ses propres avantages et inconvénients:

Les liens symboliques peuvent:

  • Pointez sur les répertoires
  • Pointez sur des objets inexistants
  • Pointez sur des fichiers et des répertoires situés hors du même système de fichiers

Les liens durs peuvent:

  • Conservez le fichier dont ils font référence à supprimer

Les liaisons matérielles sont particulièrement utiles pour exécuter des applications de "copie sur écriture". Ils vous permettent de conserver une copie de sauvegarde d'une structure de répertoire, tout en n'utilisant que de l'espace pour les fichiers qui changent entre deux versions.

La commande cp -al est particulièrement utile à cet égard. Il fait une copie complète d'une structure de répertoire, où tous les fichiers sont représentés par des liens physiques vers les fichiers d'origine. Vous pouvez ensuite procéder à la mise à jour des fichiers dans la structure, et seuls les fichiers que vous mettez à jour occupent plus d'espace. Ceci est particulièrement utile lors de la maintenance de sauvegardes multigénérationnelles.


72
2018-02-18 15:06



en ce qui concerne le dernier paragraphe, si vous modifiez le fichier "copié" avec lien physique, le fichier d'origine est également modifié - voir unix.stackexchange.com/questions/70531/… - marcin
Cette description des liens durs est plutôt trompeuse. Il est fondamentalement vrai que les liens durs "empêchent la suppression du fichier auquel ils font référence", mais cela n’est qu’un effet secondaire des liens physiques. Ce n'est certainement pas vrai que vous pouvez créer des liens durs dans un répertoire, changer le fichier "d'origine", puis attendre que les liens physiques pointent vers l'ancien contenu. En fait, la vérité qui guide les liens durs est le fait que ce n’est pas du tout un lien, du moins pas plus que le "fichier" original, qui n’est qu’un nom qui pointe vers un fichier. Un lien physique est simplement un autre nom pointant vers le même fichier. - matty
L'idée de sauvegarde est bonne et je l'utilise beaucoup, mais je pense que les utilisateurs doivent être avertis que la modification d'un fichier changera également la sauvegarde. - Mark
Heck, un lien symbolique n'a pas besoin de pointer du tout. ln -s "Don't use this directory" README est légitime. En fait, si vous y réfléchissez, un répertoire peut être utilisé comme base de données relationnelle et ne contenir aucun fichier réel. - Edward Falk
-1 Cela ne répond pas à la question, et certaines informations sont fausses. - wjandrea


FYI, vous pouvez obtenir la même chose que les liens durs pour les répertoires en utilisant mount:

mount -t bind /var/www /home/user/workspace/www

Ceci est très dangereux car la plupart des outils et des programmes ne seront pas au courant de la liaison. J'ai une fois fait quelque chose comme dans l'exemple ci-dessus et ensuite procédé à rm -rf /home/user. Heureusement, il n'y avait rien de pertinent dans /var/www.


37
2017-11-07 17:39



J'ai utilisé mount --bind <src> <dest>. Utilisez avec soin pour ne pas essuyer le src ;) - kachar
Je reçois: mount: unknown filesystem type 'bind' - Wizek
sur Busybox, c'est ça mount -o bind src dest - Mat M
@MatM même avec Debian - hanshenrik


La raison pour laquelle les répertoires de liens durs ne sont pas autorisés est un peu technique. Essentiellement, ils brisent la structure du système de fichiers. Vous ne devriez généralement pas utiliser de liens physiques de toute façon. Les liens symboliques autorisent la plupart des fonctionnalités sans causer de problèmes (par ex. ln -s target link).


18
2017-11-01 21:25



Les liens durs ont de bons cas d'utilisation. Dire que vous ne devriez généralement pas les utiliser est un peu trop large. - Sander Steffann
+2 pour avoir fourni le lien qui répond en fait à la question (et à la mienne) de l'OP, -1 pour émettre un avis ("Vous ne devriez en général pas utiliser de liens durs" - s'il avait des liens pour le supporter). Ce qui était bien, car je ne peux pas donner +2 de toute façon. ;RÉ - msb
le lien "ils brisent la structure du système de fichiers" ne fonctionne pas. - Charlie Parker
Essayez de résumer le contenu du lien dans la réponse et conservez le lien comme référence. C'est une bonne pratique d'échange de piles pour éviter la pourriture des liens, merci. - Oxwivi
bien fait @CharlieParker; meilleur commentaire involontaire (?) ironique de tous les temps :) - Eliran Malka