Zuerst eine Anmerkung:der ln Der Befehl hat keine Optionen wie -d , -F , --directory , dies ist ein nicht-portabler GNUismus.
Das gesuchte Feature wird durch link(1) implementiert Befehl.
Zurück zu Ihrer ursprünglichen Frage:
Auf einem typischen UNIX-System wird die Entscheidung, ob Hardlinks auf Verzeichnisse möglich sind, im Dateisystemtreiber getroffen.
Der Solaris UFS-Treiber unterstützt Hardlinks auf Verzeichnissen, der ZFS-Treiber nicht.
Der Grund, warum UFS auf Solaris Hardlinks unterstützt, ist, dass AT&T an dieser Funktion interessiert war – UFS von BSD unterstützt keine Hardlink-Verzeichnisse.
Der Grund, warum ZFS keine fest verknüpften Verzeichnisse unterstützt, ist, dass Jeff Bonwick diese Funktion nicht mag.
In Bezug auf Linux würde ich vermuten, dass Linux Versuche blockiert, feste Links in Verzeichnissen in den oberen Kernel-Schichten zu erstellen. Der Grund für diese Annahme ist, dass Linus Torvalds Code für GIT geschrieben hat, der Verzeichnisse schredderte, als git clone wurde als root auf einer Plattform aufgerufen, die fest verknüpfte Verzeichnisse unterstützt.
Beachten Sie, dass ein Dateisystem, das das Erstellen von fest verknüpften Verzeichnissen unterstützt, auch unlink(1) unterstützen muss um nicht leere Verzeichnisse als root zu entfernen.
Wenn wir also davon ausgehen, dass Torvalds weiß, wie Linux funktioniert, und wenn Linux fest verknüpfte Verzeichnisse unterstützt, hätte Torvalds wissen müssen, dass unlink(2) aufgerufen wird in einem Verzeichnis, während Sie root sind, wird nicht mit einem Fehler zurückkehren, sondern dieses Verzeichnis schreddern. Mit anderen Worten, es ist unwahrscheinlich, dass Linux einem Dateisystemtreiber erlaubt, fest verknüpfte Verzeichnisse zu implementieren.
In der Frage von OP wird mount --bind erwähnt . Eine schnelle Überprüfung zeigt, dass die Linkanzahl für das gemountete Verzeichnis nicht geändert wird. Hardlinking immer ändert die Linkanzahl, die Sie mit ls -ld sehen können .
Normalerweise (die meisten Unix-ähnlichen Systeme) ist die Anzahl der Hardlinks zu einem Verzeichnis die Anzahl der Verzeichnisse, die mit diesem Namen verbunden sind, z. B.
".."(das übergeordnete Verzeichnis)"."(das Verzeichnis selbst)- Unterverzeichnisse
Wenn Sie die (normalerweise) informativeren Infos lesen Seite, können Sie entdecken, wie andere es getan haben:
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".
obwohl es derzeit formuliert ist
Die meisten Systeme verbieten es, einen festen Link zu einem Verzeichnis zu erstellen; bei denen, wo es erlaubt ist, kann dies nur der Superuser tun (und mit Vorsicht, da das Erstellen eines Zyklus vielen anderen Dienstprogrammen Probleme bereiten wird). Feste Links können Dateisystemgrenzen nicht überschreiten. (Diese Einschränkungen werden jedoch nicht von POSIX vorgeschrieben.)
Das Erstellen (und Entfernen) von Hardlinks zu einem Verzeichnis ist eine eingeschränkte Funktion, um vor dem Verlust von Dateien zu schützen, wenn ein Verzeichnis nicht verknüpft ist. Weil die Link-/Unlink-Operationen an der Schnittstelle des C-Betriebssystems symmetrisch sind , das Verlinken auf Verzeichnisse erfolgt normalerweise nur in mkdir/rmdir-Aufrufen.
Denken Sie daran, dass ein Großteil der GNU-Coreutils vor 20-30 Jahren geschrieben (und dokumentiert) wurde, als einige echte Museumsstücke noch in Gebrauch waren. Wie in Bezug auf Hard Link erwähnt, gab es ursprünglich waren keine mkdir/rmdir-Aufrufe; Verzeichnisse wurden (als privilegierter Vorgang) mithilfe von Hardlinks erstellt. All das verschwand, als die Systemaufrufe hinzugefügt wurden, um die erwähnten Probleme zu lösen. Aber die Dokumentation bezieht sich weiterhin auf diese Systeme über die Erinnerung ihrer Betreuer hinaus. Die in Frage gestellte Option war im Vorgänger fileutils (was mit textutils kombiniert wurde und shellutils Mitte der 1990er Jahre zur Gründung von coreutils ). Ein paar Einträge aus dem Änderungsprotokoll können helfen, den Ursprung des Features zu klären:
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.
So können Sie beispielsweise sehen, dass eine der Antiquitäten, für die diese Funktion anwendbar war, SunOS war. Die entsprechende Handbuchseite sagte dies:
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.
Wie in der Dokumentation erwähnt, sind diese Funktion (und die entsprechende Option) nicht in POSIX (und siehe Begründung Abschnitt, der erklärt, warum). Stattdessen wurde die Funktion in einen neuen Befehl (der auch von GNU Coreutils bereitgestellt wird) namens link verschoben . Die Beschreibung des Befehls selbst ist vage; Sie müssen die Beschreibung des Funktionsaufrufs lesen, um vom Standard Gebrauch zu machen. Der Standard verdeutlicht jedoch nicht die Bedingungen, unter denen der Befehl funktionieren würde, abgesehen von der Übernahme des Haftungsausschlusses über erforderliche Berechtigungen. Dazu müssen Sie zu systemabhängigen Funktionen außerhalb des Standards gehen:
Das Verknüpfen mit einem Verzeichnis ist in den meisten historischen Implementierungen auf den Superuser beschränkt, da diese Fähigkeit Schleifen in der Dateihierarchie erzeugen oder das Dateisystem anderweitig beschädigen kann. Dieser Band von POSIX.1-2008 setzt diese Philosophie fort, indem er link() verbietet und unlink() davon ab, dies zu tun. Andere Funktionen könnten dies tun, wenn der Implementierer eine solche Erweiterung entworfen hätte.
Es gibt Systeme, die Hardlinks zu Verzeichnissen über die normale Anzahl hinaus verwenden (2 plus Unterverzeichnisse).
OSX verwendet mehrere Hardlinks zu Verzeichnissen für gewöhnliche Dateien . Dies wird bei Verwendung von ln nicht unterstützt (siehe Handbuchseite). Laut How Time Machine Works its Magic tut es dies, um die Versionen bereitzustellen, die für die Sicherungsfunktion von Time Machine verwendet werden.
Weiterführende Literatur:
- Warum erstellt OS X Time Machine Verzeichnis-Hardlinks?
- Wie lautet der Unix-Befehl zum Erstellen eines Hardlinks zu einem Verzeichnis in OS X?