D'abord une note :le ln la commande n'a pas d'options comme -d , -F , --directory , il s'agit d'un GNUisme non portable.
La fonctionnalité que vous recherchez est implémentée par le link(1) commande.
Revenons à votre question d'origine :
Sur un système UNIX typique, la décision de savoir si des liens physiques sur les répertoires sont possibles est prise dans le pilote du système de fichiers.
Le pilote Solaris UFS prend en charge les liens physiques sur les répertoires, contrairement au pilote ZFS.
La raison pour laquelle UFS sur Solaris prend en charge les liens physiques est qu'AT&T était intéressé par cette fonctionnalité - UFS de BSD ne prend pas en charge les répertoires liés en dur.
La raison pour laquelle ZFS ne prend pas en charge les répertoires liés en dur est que Jeff Bonwick n'aime pas cette fonctionnalité.
En ce qui concerne Linux, je suppose que Linux bloque les tentatives de création de liens physiques sur les répertoires des couches supérieures du noyau. La raison de cette hypothèse est que Linus Torvalds a écrit du code pour GIT qui détruisait les répertoires lorsque git clone a été appelé en tant que root sur une plate-forme prenant en charge les répertoires liés en dur.
Notez qu'un système de fichiers qui prend en charge la création de répertoires liés en dur doit également prendre en charge unlink(1) pour supprimer les répertoires non vides en tant que root.
Donc, si nous supposons que Torvalds sait comment Linux fonctionne et si Linux prend en charge les répertoires liés en dur, Torvalds aurait dû savoir qu'appeler unlink(2) sur un répertoire tout en étant root, ne renverra pas avec une erreur mais détruira ce répertoire. EN d'autres termes, il est peu probable que Linux permette à un pilote de système de fichiers d'implémenter des répertoires liés en dur.
La question d'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é. Lien dur toujours modifie 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 les informations (généralement) plus informatives page, 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 d'établir un lien physique vers un répertoire ; sur ceux où c'est autorisé, seul le super-utilisateur peut le faire (et avec prudence, car la création d'un cycle posera des problèmes à de nombreux autres utilitaires). Les liens physiques ne peuvent pas traverser les limites du système de fichiers. (Ces restrictions ne sont cependant 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é. Parce 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 de GNU coreutils a été écrite (et documentée) il y a 20 à 30 ans, lorsque de véritables pièces de musée étaient encore utilisées. Comme indiqué dans Concernant le lien physique, à l'origine il 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 mainteneurs. L'option qui a été remise en question était dans le prédécesseur fileutils (qui a été combiné avec textutils et shellutils au milieu des années 1990 pour 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 Rationale section 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 tirer parti de la norme. Cependant, la norme ne clarifie pas les conditions dans lesquelles la commande fonctionnerait, mis à part le report de la clause de non-responsabilité concernant les privilèges requis. Pour cela, il faut aller vers des fonctionnalités dépendantes du système hors standard :
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()etunlink()de faire ça. D'autres fonctions pourraient le faire si l'implémenteur avait conçu une telle extension.
Il y a systèmes qui utilisent des liens physiques vers des répertoires au-delà du nombre normal (2 plus sous-répertoires).
OSX utilise plusieurs liens physiques vers des répertoires pour les fichiers ordinaires . Il ne prend pas en charge cela en utilisant ln (voir page de manuel). Selon How Time Machine Works its Magic, il le fait pour fournir les versions utilisées pour la fonction de sauvegarde Time Machine.
Lectures complémentaires :
- Pourquoi OS X Time Machine crée-t-il des liens physiques vers les répertoires ?
- Quelle est la commande Unix pour créer un lien physique vers un répertoire sous OS X ?