Aus der Manpage für ln :
-d, -F, --directory
allow the superuser to attempt to hard link directories (note: will
probably fail due to system restrictions, even for the superuser)
Gibt es Dateisystemtreiber, die dies tatsächlich zulassen, oder ist dies die einzige Option mount --bind <src> <dest>? Oder wird diese Art von Verhalten vom Kernel blockiert, bevor er überhaupt zum dateisystemspezifischen Treiber gelangt?
HINWEIS: Ich habe nicht vor, dies auf Maschinen zu tun, nur neugierig.
Antworten:
Zunächst wird eine Anmerkung: der lnBefehl keine Optionen wie -d, -F, --directoryist dies eine nicht tragbare GNUism.
Die gesuchte Funktion wird vom link(1)Befehl implementiert .
Zurück zu Ihrer ursprünglichen Frage:
Auf einem typischen UNIX-System wird im Dateisystemtreiber entschieden, ob feste Verknüpfungen zu Verzeichnissen möglich sind.
Der Solaris UFS-Treiber unterstützt Hardlinks in Verzeichnissen, der ZFS-Treiber nicht.
Der Grund, warum UFS unter 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-Layern zu erstellen. Der Grund für diese Annahme ist, dass Linus Torvalds Code für GIT geschrieben hat, der Verzeichnisse vernichtet hat, als git cloneer als Root auf einer Plattform aufgerufen wurde, die fest verknüpfte Verzeichnisse unterstützt.
Beachten Sie, dass ein Dateisystem, das das Erstellen fest verknüpfter Verzeichnisse unterstützt unlink(1), auch das Entfernen nicht leerer Verzeichnisse als Root unterstützen muss.
Wenn wir also davon ausgehen, dass Torvalds weiß, wie Linux funktioniert, und wenn Linux fest verknüpfte Verzeichnisse unterstützt, sollte Torvalds wissen, dass der Aufruf unlink(2)eines Verzeichnisses als Root nicht mit einem Fehler zurückkehrt, sondern dieses Verzeichnis vernichtet. Mit anderen Worten, es ist unwahrscheinlich, dass Linux einem Dateisystemtreiber erlaubt, fest verknüpfte Verzeichnisse zu implementieren.
In der Frage von OP wird erwähnt mount --bind. Eine schnelle Überprüfung zeigt, dass die Anzahl der Links für das gemountete Verzeichnis nicht geändert wird. Durch das Hardlinking wird immer die Anzahl der Links geändert , die Sie mit sehen können ls -ld.
Normalerweise (die meisten Unix-ähnlichen Systeme) entspricht die Anzahl der Hardlinks zu einem Verzeichnis der Anzahl der mit diesem Namen verbundenen Verzeichnisse, z.
".." (das übergeordnete Verzeichnis)"." (das Verzeichnis selbst)Wenn Sie die ( in der Regel) informative lesen Info - Seite, können Sie entdecken , wie andere 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 das Herstellen einer festen Verbindung zu einem Verzeichnis. In den Fällen, in denen dies zulässig ist, kann dies nur der Superuser tun (und dies mit Vorsicht, da das Erstellen eines Zyklus vielen anderen Dienstprogrammen Probleme bereitet). Hardlinks können keine Dateisystemgrenzen überschreiten. (Diese Einschränkungen werden jedoch von POSIX nicht vorgeschrieben.)
Das Erstellen (und Entfernen) von Hardlinks zu einem Verzeichnis ist eine eingeschränkte Funktion, um den Verlust von Dateien zu verhindern, wenn ein Verzeichnis nicht verknüpft ist. Da die Verknüpfungs- / Aufhebungsvorgänge an der C-Betriebssystemschnittstelle symmetrisch sind , erfolgt die Verknüpfung mit Verzeichnissen normalerweise nur in mkdir / rmdir-Aufrufen.
Denken Sie daran, dass ein Großteil der GNU-Coreutils vor 20 bis 30 Jahren geschrieben (und dokumentiert) wurde, als noch einige echte Museumsstücke verwendet wurden. Wie in Bezug auf Hard Link erwähnt , gab es ursprünglich keine mkdir / rmdir-Aufrufe. Verzeichnisse wurden (als privilegierte Operation) unter Verwendung von festen Links erstellt. All das ging verloren, als die Systemaufrufe hinzugefügt wurden, um die genannten Probleme zu lösen. Die Dokumentation bezieht sich jedoch weiterhin auf diese Systeme, die über den Speicher ihrer Betreuer hinausgehen. Die Option, die in Frage gestellt wurde, war beim Vorgänger fileutils(der mit textutilsund shellutilsMitte der neunziger Jahre kombiniert wurde, um sich zu bilden coreutils). Einige Elemente aus dem Änderungsprotokoll können helfen, den Ursprung der Funktion zu verdeutlichen:
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 zum Beispiel 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, ist diese Funktion (und die entsprechende Option nicht in POSIX enthalten (siehe Abschnitt " Begründung ", in dem erläutert wird, warum)). Die Funktion wurde vielmehr in einen neuen Befehl (auch von GNU coreutils bereitgestellt) mit dem Namen " linkDie Beschreibung von" verschoben Der Befehl selbst ist vage. Sie müssen die Beschreibung des Funktionsaufrufs lesen , um eine Verwendung aus dem Standard zu erhalten. Der Standard klärt jedoch nicht die Bedingungen, unter denen der Befehl funktionieren würde, abgesehen davon, dass der Haftungsausschluss über die erforderlichen Berechtigungen übertragen wird. Dazu müssen Sie zu systemabhängigen Funktionen außerhalb des Standards wechseln:
Das Verknüpfen mit einem Verzeichnis ist in den meisten historischen Implementierungen auf den Superuser beschränkt, da diese Funktion Schleifen in der Dateihierarchie erzeugen oder das Dateisystem auf andere Weise beschädigen kann. Dieser Band von POSIX.1-2008 setzt diese Philosophie fort, indem er dies verbietet
link()undunlink()tut. Andere Funktionen könnten dies tun, wenn der Implementierer eine solche Erweiterung entwirft.
Es gibt Systeme, die Hardlinks zu Verzeichnissen verwenden, die über die normale Anzahl hinausgehen (2 plus Unterverzeichnisse).
OSX verwendet mehrere Hardlinks zu Verzeichnissen für normale Dateien . Dies wird mit nicht unterstützt ln(siehe Handbuchseite ). Je nachdem , wie Time Machine funktioniert , werden die für die Time Machine-Sicherungsfunktion verwendeten Versionen bereitgestellt.
Weiterführende Literatur: