La question de l'OP mentionne mount --bind. Une vérification rapide montre qu'il ne modifie pas le nombre de liens pour le répertoire qui est monté. Le hardlinking modifie toujours le nombre de liens, que vous pouvez voir en utilisant ls -ld.
Normalement (la plupart des systèmes de type Unix), le nombre de liens physiques vers un répertoire sera le nombre de répertoires connectés à ce nom, par exemple,
".." (le répertoire parent)"." (le répertoire lui-même)- sous-répertoires
Si vous lisez la page d' informations (généralement) plus informative , vous découvrirez peut-être, comme d' autres l' ont fait:
Oh great, one spends hours tying to find what is wrong only to
discover,
$ info ln
On all existing implementations, you cannot make a hard link to a
directory, and hard links cannot cross filesystem boundaries. (These
restrictions are not mandated by POSIX, however.)
Therefore, kindly say everywhere you say super-user only,
instead say "few systems, super-user only".
bien qu'il soit actuellement libellé
La plupart des systèmes interdisent de créer un lien dur vers un répertoire; sur ceux où cela est autorisé, seul le super-utilisateur peut le faire (et avec prudence, car la création d'un cycle causera des problèmes à de nombreux autres utilitaires). Les liens matériels ne peuvent pas franchir les limites du système de fichiers. (Ces restrictions ne sont toutefois pas imposées par POSIX.)
La création (et la suppression) de liens physiques vers un répertoire est une fonctionnalité restreinte pour éviter de perdre des fichiers si un répertoire n'est pas lié. Étant donné que les opérations de liaison / dissociation à l'interface du système d'exploitation C sont symétriques , la liaison aux répertoires se fait normalement uniquement dans les appels mkdir / rmdir.
Gardez à l'esprit qu'une grande partie des coreutils GNU a été écrite (et documentée) il y a 20-30 ans, alors que de véritables pièces de musée étaient encore utilisées. Comme indiqué dans Concernant Hard Link , à l'origine il n'y avait pas d'appels mkdir / rmdir; les répertoires ont été créés (en tant qu'opération privilégiée) à l'aide de liens physiques. Tout cela a disparu lorsque les appels système ont été ajoutés pour résoudre les problèmes mentionnés. Mais la documentation continue de faire référence à ces systèmes au-delà de la mémoire de leurs responsables. L'option qui a été mise en cause était celle du prédécesseur fileutils(qui a été combinée avec textutilset shellutilsau milieu des années 90 pour se former coreutils). Quelques éléments du journal des modifications peuvent aider à clarifier l'origine de la fonctionnalité:
Mon Jul 23 16:57:44 1990 David J. MacKenzie (djm at albert.ai.mit.edu)
* cp.c (copy): Make +update operate silently, like +one-file-system.
* ln.c: Add -F as synonym for -d, for SunOS compatibility.
Wed Feb 21 11:13:26 1990 David J. MacKenzie (djm at albert.ai.mit.edu)
* ln.c (error): New function.
(main, do_link): Call error instead of fprintf and exit.
(main): Recognize new -d +directory option to allow superuser to
make hard links to dirs, like the BSD ln -f option.
(do_link): Don't allow hard links to dirs (they are hard to
get rid of -- rmdir and unlink don't do it), unless -d was given.
(usage): Mention -d +directory option.
Ainsi, vous pouvez voir par exemple que l'une des antiquités pour lesquelles cette fonctionnalité était applicable était SunOS. La page de manuel correspondante disait ceci:
OPTIONS
-f Force a hard link to a directory -- this option is only avail-
able to the super-user.
-s Create a symbolic link or links.
SYSTEM V OPTIONS
-f Force files to be linked without displaying permissions, asking
questions or reporting errors.
-F Force a hard link to a directory -- this option is only avail-
able to the super-user.
-s Create a symbolic link or links.
Comme indiqué dans la documentation, cette fonctionnalité (et l'option correspondante ne sont pas dans POSIX (et voir la section Justification qui explique pourquoi). Au lieu de cela, la fonctionnalité a été déplacée vers une nouvelle commande (fournie également par GNU coreutils) appelée link. La description de la commande elle-même est vague; vous devez lire la description de l' appel de fonction pour obtenir une quelconque utilisation de la norme. Cependant, la norme ne clarifie pas les conditions dans lesquelles la commande fonctionnerait, en plus de reporter l'avertissement sur les privilèges requis. Pour cela, vous devez accéder à des fonctionnalités dépendant du système en dehors de la norme:
La liaison à un répertoire est limitée au superutilisateur dans la plupart des implémentations historiques car cette capacité peut produire des boucles dans la hiérarchie des fichiers ou corrompre le système de fichiers. Ce volume de POSIX.1-2008 poursuit cette philosophie en interdisant link()et en unlink()faisant cela. D'autres fonctions pourraient le faire si l'implémenteur a conçu une telle extension.
Il existe des systèmes qui utilisent des liens physiques vers des répertoires au-delà du nombre normal (2 sous-répertoires plus).
OSX utilise plusieurs liens physiques vers des répertoires pour les fichiers ordinaires . Il ne prend pas en charge cette utilisation ln(voir la page de manuel ). Selon How Time Machine Works its Magic , il le fait pour fournir les versions utilisées pour la fonction de sauvegarde de Time Machine.
Lectures complémentaires: