Warum sind feste Links zu Verzeichnissen unter UNIX / Linux nicht zulässig?

Dies ist wie dort nur eine schlechte Idee Dies ist keine Möglichkeit, den Unterschied zwischen einem festen Link und einem ursprünglichen Namen zu erkennen.

Das Zulassen von festen Links zu Verzeichnissen würde die gerichtete azyklische Diagrammstruktur des Dateisystems beschädigen und möglicherweise Verzeichnisschleifen und baumelnde Verzeichnisunterbäume erzeugen Machen Sie fsck und alle anderen File Tree Walker fehleranfällig.

Um dies zu verstehen, sprechen wir zunächst über Inodes. Die Daten im Dateisystem werden in gespeichert Blöcke auf der Festplatte, und diese Blöcke werden von einem Inode zusammengetragen. Sie können sich den Inode als DIE Datei vorstellen. Inodes fehlen jedoch Dateinamen. Hier kommen Links ins Spiel.

Ein Link ist einfach ein Zeiger auf eine Inode. Ein Verzeichnis ist ein Inode, der Links enthält. Jeder Dateiname in einem Verzeichnis ist nur ein Link zu einem Inode. Durch das Öffnen einer Datei unter Unix wird ebenfalls ein Link erstellt, es handelt sich jedoch um einen anderen Linktyp (es handelt sich nicht um einen benannten Link).

Ein fester Link ist nur ein zusätzlicher Verzeichniseintrag, der auf diesen Inode verweist. Wenn Sie ls -l verwenden, ist die Nummer nach den Berechtigungen die Anzahl der benannten Links. Die meisten regulären Dateien haben einen Link. Wenn Sie einen neuen festen Link zu einer Datei erstellen, verweisen beide Dateinamen auf denselben Inode. Hinweis:

% ls -l test ls: test: No such file or directory % touch test % ls -l test -rw-r--r-- 1 danny staff 0 Oct 13 17:58 test % ln test test2 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 % touch test3 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 ^ ^ this is the link count 

Jetzt können Sie deutlich erkennen, dass es keinen festen Link gibt. Ein fester Link entspricht einem regulären Namen. Im obigen Beispiel test oder test2, welches ist die Originaldatei und welches ist der feste Link? Am Ende können Sie nicht wirklich sagen (auch nicht durch Zeitstempel), da beide Namen auf denselben Inhalt und denselben Inode verweisen:

% ls -li test* 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 14445892 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 

Das -i -Flag auf ls zeigt Ihnen Inode-Nummern am Zeilenanfang. Beachten Sie, wie test und test2 haben dieselbe Inode-Nummer, aber test3 hat eine andere.

Nun, wenn Sie das durften Wenn Sie dies für Verzeichnisse tun, können zwei verschiedene Verzeichnisse an verschiedenen Stellen im Dateisystem auf dasselbe verweisen. Tatsächlich kann ein Unterverzeichnis auf seine Großeltern verweisen und eine Schleife erstellen.

Warum ist diese Schleife ein Problem? ? Denn wenn Sie durchlaufen, gibt es keine Möglichkeit zu erkennen, dass Sie sich in einer Schleife befinden (ohne die Inode-Nummern beim Durchlaufen zu verfolgen). Stellen Sie sich vor, Sie schreiben den Befehl du, der benötigt wird Durchsuchen Sie die Unterverzeichnisse, um Informationen zur Festplattennutzung zu erhalten. Wie würde du wissen, ob n es eine Schleife getroffen? Es ist fehleranfällig und eine Menge Buchhaltung, die du tun müsste, um diese einfache Aufgabe zu erledigen.

Symlinks sind ein ganz anderes Biest dass es sich um eine spezielle Art von „Datei“ handelt, der viele Dateisystem-APIs automatisch folgen. Beachten Sie, dass ein Symlink auf ein nicht vorhandenes Ziel verweisen kann, da er nach Namen und nicht direkt auf einen Inode verweist. Dieses Konzept ist bei Hardlinks nicht sinnvoll, da die bloße Existenz eines „Hardlinks“ bedeutet, dass die Datei vorhanden ist.

Warum kann du damit umgehen? Symlinks leicht und keine festen Links? Wir konnten oben sehen, dass harte Links nicht von normalen Verzeichniseinträgen zu unterscheiden sind. Symlinks sind jedoch speziell, erkennbar und überspringbar! du stellt fest, dass die symlink ist ein symlink und überspringt ihn vollständig!

% ls -l total 4 drwxr-xr-x 3 danny staff 102 Oct 13 18:14 test1/ lrwxr-xr-x 1 danny staff 5 Oct 13 18:13 test2@ -> test1 % du -ah 242M ./test1/bigfile 242M ./test1 4.0K ./test2 242M . 

Kommentare

• Allowing hard links to directories would break the directed acyclic graph structure of the filesystem.Können Sie bitte mehr über das Problem mit Zyklen unter Verwendung von Hardlinks erklären? Warum ist es mit Symlinks in Ordnung?
• Sie scheinen es auf Macs zugelassen zu haben, indem sie dem Systemaufruf link () eine Zykluserkennung hinzugefügt haben und sich geweigert haben, einen Verzeichnis-Hardlink zu erstellen, wenn dadurch ein Zyklus erstellt würde . Scheint eine vernünftige Lösung zu sein.
• @psusi mkdir -p a / b; nocheckln c a; mv c a / b; – das nocheckln gibt es eine theoretische ln, die nicht nach Verzeichnisargumenten sucht und nur zum Link übergeht, und weil kein Zyklus gemacht wird, sind wir alle gut darin, ‚ c ‚. dann verschieben wir ‚ c ‚ in ‚ a / b ‚ und ein Zyklus wird aus a / b / c erstellt – > a / – das Einchecken von link () ist nicht gut genug
• Zyklen sind sehr schlecht. Windows hat dieses Problem mit “ Junctions „, bei denen es sich um Hardlink-Verzeichnisse handelt. Wenn Sie versehentlich Berechtigungen auf Ihr gesamtes Profil anwenden, werden eine Reihe von Knotenpunkten aufgedeckt, die einen unendlichen Zyklus erzeugen. Das Durchlaufen der Verzeichnisse wird wiederholt, bis die Pfadlängenbeschränkungen es beenden.
• @WhiteWinterWolf Laut diesem Link wurde speziell die Unterstützung für die Zeitmaschine hinzugefügt, aber nur root darf dies tun: superuser.com/questions/360926/…

Mit bind mount können Sie Verzeichnisse mit fester Verknüpfung simulieren.

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory sudo umount /else/dummy_but_existing_directory 

Mit Ausnahme der Mountpunkte hat jedes Verzeichnis ein einziges übergeordnetes Element: ...

Ein Weg zu pwd überprüft das Gerät: inode auf „.“ und „..“. Wenn sie identisch sind, haben Sie das Stammverzeichnis des Dateisystems erreicht. Suchen Sie andernfalls den Namen des aktuellen Verzeichnisses im übergeordneten Verzeichnis, verschieben Sie diesen auf einen Stapel und vergleichen Sie „../“. mit „../ ..“, dann „../../.“ mit „../../ ..“ usw. Sobald Sie das Stammverzeichnis erreicht haben, beginnen Sie mit dem Löschen und Drucken der Namen vom Stapel. Dieser Algorithmus basiert auf der Tatsache, dass jedes Verzeichnis nur ein übergeordnetes Verzeichnis hat.

Wenn feste Links zu Verzeichnissen zulässig wären, auf welchen der mehreren übergeordneten Elternteile sollte .. verweisen? Dies ist ein zwingender Grund, warum Hardlinks zu Verzeichnissen nicht zulässig sind.

Symlinks zu Verzeichnissen verursachen dieses Problem nicht. Wenn ein Programm dies möchte, kann es für jeden Teil des Pfadnamens eine lstat() ausführen und erkennen, wenn ein Symlink gefunden wird. Der Algorithmus pwd gibt den wahren absoluten Pfadnamen für ein Zielverzeichnis zurück. Die Tatsache, dass irgendwo ein Text (der Symlink) auf das Zielverzeichnis verweist, ist ziemlich irrelevant. Das Vorhandensein eines solchen Symlinks erzeugt keine Schleife im Diagramm.

Kommentare

• Da bin ich mir nicht so sicher. Wenn wir uns .. als eine Art virtuellen Hardlink zum übergeordneten Link vorstellen, gibt es keinen technischen Grund dafür, dass das Ziel des Links nur einen anderen Link haben kann. pwd müsste nur einen anderen Algorithmus verwenden, um den Pfad aufzulösen.

Keiner der folgenden Gründe ist der wahre Grund dafür, dass harte Links zu Verzeichnissen nicht zulässig sind. Jedes Problem ist ziemlich einfach zu lösen:

• Zyklen in der Baumstruktur verursachen eine schwierige Durchquerung
• mehrerer Eltern. Welches ist also das „echte“?

li> Dateisystem-Speicherbereinigung

Der wahre Grund (wie von @ Thorbjørn Ravn angedeutet) Andersen) kommt, wenn Sie ein Verzeichnis mit mehreren übergeordneten Elementen aus dem Verzeichnis löschen, auf das :

Worauf sollte .. jetzt verweisen?

Wenn das Verzeichnis von seinem übergeordneten Verzeichnis gelöscht wird, aber die Anzahl der Links ist immer noch größer als 0, dann muss es etwas geben, das irgendwo noch darauf hinweist. Sie können .. nicht auf nichts verweisen lassen; viele Programme basieren auf .., sodass das System das durchlaufen müsste gesamtes Dateisystem , bis es das erste findet, das auf das gelöschte Verzeichnis verweist, nur um .. zu aktualisieren. Entweder das, oder das Dateisystem müsste eine Liste von führen Alle Verzeichnisse, die auf ein fest verknüpftes Verzeichnis verweisen.

In beiden Fällen wäre dies ein Leistungsaufwand und eine zusätzliche Komplikation für die Metadaten und / oder den Code des Dateisystems, sodass die Designer beschlossen, dies nicht zuzulassen.

Kommentare

• Das ‚ ist ebenfalls leicht zu lösen: Führen Sie eine Liste der Eltern eines untergeordneten Verzeichnisses. die Sie aktualisieren, wenn Sie einen Link zum Kind hinzufügen oder entfernen. Wenn Sie das kanonische Elternteil löschen (das Ziel des Kindes ‚ s

  ), aktualisieren Sie .., um auf einen der anderen Elternteile in der Liste zu verweisen.

• Ich stimme zu. Keine Raketenwissenschaft zu lösen. Trotzdem ein Leistungsaufwand, der ein wenig zusätzlichen Speicherplatz in den Metadaten des Dateisystems beanspruchen und Komplikationen verursachen würde. Und so entschieden sich die Designer für den einfachen, schnellen Ansatz – ‚ erlaubt keine Links zu harten Verzeichnissen.
• Sym-Links zu Verzeichnissen “ verstößt gegen festgelegte Semantik und Verhaltensweisen „, sie sind jedoch weiterhin zulässig. Einige Befehle benötigen daher Optionen, um zu steuern, ob Sym-Links befolgt werden (z. B. -L in find und cp). Wenn ein Programm ‚ .. ‚ folgt, gibt es weitere Verwirrung, daher der Unterschied in der Ausgabe von pwd und / bin / pwd nach dem Durchlaufen von a sym link. Es gibt keine “ Unix-Antworten „; nur Designentscheidungen. Dieser dreht sich um das, was aus “ .. “ wird, wie ich in meiner Antwort angegeben habe. Leider wird ‚ .. ‚ nicht ‚ in der Antwort, die alle anderen erwähnt haben, nicht einmal erwähnt stimmt so verlegen dafür.
• Übrigens, ich ‚ sage nicht, dass ich ‚ für harte Links bin zu dirs. Gar nicht. Ich ‚ möchte nicht, dass mein Tagesjob schwieriger wird als er bereits ist.
• ‚ ist nicht was POSIX sagt, aber IMO ‚ .. ‚ sollte niemals ein Dateisystemkonzept gewesen sein, sondern syntaktisch auf den Pfaden aufgelöst werden, so dass a/.. würde immer . bedeuten. So funktionieren übrigens URLs. ‚ ist der Browser, der ‚ ‚ auflöst. ‚ bevor es überhaupt auf den Server trifft. Und es funktioniert hervorragend.

Die Erstellung von Hardlinks in Verzeichnissen wäre nicht rückgängig zu machen. Angenommen, wir haben:

/dir1 ├──this.txt ├──directory │ └──subfiles └──etc 

Ich verknüpfe es fest mit /dir2.

Also /dir2 enthält jetzt auch alle diese Dateien und Verzeichnisse

Was ist, wenn ich meine Meinung ändere? Ich kann „nicht nur rmdir /dir2 (weil es nicht leer ist)

und wenn ich rekursiv in /dir2 lösche. .. es wird auch aus /dir1 gelöscht!

IMHO ist dies ein weitgehend ausreichender Grund, dies zu vermeiden!

Bearbeiten:

Kommentare schlagen vor, das Verzeichnis zu entfernen, indem Sie rm darauf ausführen .rm in einem nicht leeren Verzeichnis schlägt jedoch fehl, und dieses Verhalten muss bestehen bleiben, unabhängig davon, ob das Verzeichnis fest verknüpft ist oder nicht. Sie können also „nicht nur rm, um die Verknüpfung aufzuheben. Es würde ein neues Argument für rm erfordern, nur um zu sagen“, wenn das Verzeichnis inode ist hat einen Referenzzähler> 1 und hebt dann nur die Verknüpfung des Verzeichnisses auf. „

Dies wiederum verstößt gegen ein anderes Prinzip der geringsten Überraschung: Das Entfernen eines soeben erstellten Verzeichnis-Hardlinks ist nicht dasselbe wie das Entfernen eines normalen Datei-Hardlinks …

Ich werde meinen Satz umformulieren: Ohne weitere Entwicklung wäre die Hardlink-Erstellung nicht rückgängig zu machen (da kein aktueller Befehl das Entfernen handhaben könnte, ohne mit dem aktuellen Verhalten inkohärent zu sein)

Wenn wir mehr Entwicklung zulassen, um den Fall zu behandeln, die Anzahl der Fallstricke und das Risiko eines Datenverlusts , wenn Sie „Wenn man sich nicht genug darüber im Klaren ist, wie das System funktioniert, impliziert eine solche Entwicklung, ist meiner Meinung nach ein ausreichender Grund, die Hardlinking-Verzeichnisse einzuschränken.

Kommentare

• Das sollte kein Problem sein. In Ihrem Fall müssen wir beim Erstellen eines Hardlinks zu dir2 einen Hardlink zu allen Inhalten in dir1 erstellen. Wenn wir also dir2 umbenennen oder löschen, wird nur ein zusätzlicher Link zum Inode gelöscht. Dies sollte sich nicht auf dir1 und seinen Inhalt auswirken, da mindestens ein Link (dir1) zum Inode vorhanden ist.
• Ihr Argument ist falsch. Sie würden es einfach aufheben, nicht rm -rf. Und wenn die Anzahl der Links 0 erreicht, weiß das System, dass es auch den gesamten Inhalt löschen kann.
• Das ‚ ist mehr oder weniger alles rm funktioniert sowieso darunter (Verknüpfung aufheben). Siehe: unix.stackexchange.com/questions/151951/… Dies ist wirklich nicht ‚ kein Problem, genauso wenig wie bei fest verknüpften Dateien. Durch das Aufheben der Verknüpfung wird nur die benannte Referenz entfernt und die Anzahl der Verknüpfungen verringert. Die Tatsache, dass rmdir ‚ keine nicht leeren Verzeichnisse löscht, ist irrelevant – es würde nicht ‚ Tun Sie das auch nicht für dir1. Hardlinks sind keine ‚ Kopien von Daten, sie sind dieselbe tatsächliche Datei, daher wird “ “ Die dir2-Datei würde die Verzeichnisliste für dir1 löschen. Sie müssten immer die Verknüpfung aufheben.
• Sie können ‚ die Verknüpfung nicht einfach wie eine normale Datei aufheben, da rm in einem Verzeichnis don ‚ t die Verknüpfung aufheben, wenn ‚ nicht leer ist. Siehe Bearbeiten.

Dies ist eine gute Erklärung. Zu „Auf welchen der mehreren Elternteile sollte … hingewiesen werden?“ Eine Lösung wäre, dass ein Prozess seinen vollständigen wd-Pfad entweder als Inodes oder als Zeichenfolge beibehält. Inodes wären robuster, da Namen geändert werden können. Zumindest in den alten Tagen gab es für jede geöffnete Datei einen In-Core-Inode, der beim Öffnen einer Datei inkrementiert und beim Schließen dekrementiert wurde. Wenn es Null erreicht hat, wird der Speicher, auf den es zeigt, freigegeben. Wenn die Datei von niemandem mehr geöffnet wurde, wurde sie (die In-Core-Kopie) abgebrochen. Dies würde den Pfad als gültig beibehalten, wenn ein anderer Prozess ein Verzeichnis in ein anderes Verzeichnis verschiebt, während sich das Unterverzeichnis im Pfad eines anderen Prozesses befindet. Ähnlich wie Sie eine geöffnete Datei löschen können, diese jedoch einfach aus dem Verzeichnis entfernt wird, aber dennoch für alle Prozesse geöffnet ist, bei denen sie geöffnet ist.

Das Verknüpfen von Verzeichnissen war in Bell Labs UNIX früher frei zulässig. Zumindest V6 und V7, ich weiß nichts über Berkeley oder später. Keine Flagge erforderlich. Könnten Sie Schleifen machen? Ja, tun Sie das nicht. Es ist sehr klar, was Sie tun, wenn Sie eine Schleife machen. Nether sollten Sie üben, Knoten um Ihren Hals zu binden, während Sie darauf warten, dass Sie an der Reihe sind, aus einem Flugzeug zu springen, wenn Sie das andere Ende bequem an einem Haken am Schott aufgehängt haben.

Was Ich hatte gehofft, heute damit zu tun zu haben, lhome fest mit home zu verbinden, damit ich / home / administ zur Verfügung habe, unabhängig davon, ob / home mit einem Automout über Home verdeckt war oder nicht, wobei automount einen Symlink namens administ hatte an / lhome / administ. Auf diese Weise kann ich über ein Administratorkonto verfügen, das unabhängig vom Status meines primären Home-Dateisystems funktioniert. Dies IS ist ein Experiment für Linux, aber ich denke, es wurde einmal für das UCB-basierte SunOS gelernt, dass Automounts auf der Ebene der ASCII-Zeichenfolgen durchgeführt werden. Es ist schwer zu erkennen, wie sie ansonsten als Schicht über einem beliebigen FS ausgeführt werden könnten.

Ich habe das an anderer Stelle gelesen. und .. sind auch keine Dateien mehr im Verzeichnis. Ich bin mir sicher, dass es dafür gute Gründe gibt und dass vieles, was uns Spaß macht (wie das Mounten von NTFS), aufgrund solcher Dinge möglich ist, aber ein Teil der Eleganz von UNIX lag in der Implementierung.Es sind die Vorteile wie Allgemeinheit und Formbarkeit, die diese Eleganz bietet, die es ermöglicht haben, so robust zu sein und vier Jahrzehnte lang zu bestehen. Wenn wir die eleganten Implementierungen verlieren, wird es irgendwann wie Windows (ich hoffe, ich liege falsch!). Jemand würde dann ein neues Betriebssystem erstellen, das auf eleganten Prinzipien basiert. Etwas zum Nachdenken. Vielleicht irre ich mich, ich bin (offensichtlich) nicht mit der aktuellen Implementierung vertraut. Es ist erstaunlich, wie anwendbar das 30-jährige Verständnis auf Linux ist … die meiste Zeit!

Kommentare

• Ich denke, obwohl ich falsch liegen kann, dass . und .. für moderne Dateisysteme keine Hardlinks im Dateisystem sind. Der Dateisystemtreiber fälscht sie jedoch. Es ist dieses Dateisystem, das die Verknüpfung von Verzeichnissen verhindert. Für alte Dateisysteme war es möglich (aber gefährlich). Um zu tun, was Sie versuchen, schauen Sie sich mount --bind an, siehe auch mount --make… und möglicherweise Container.

Soweit ich weiß, ist der Hauptgrund, dass es nützlich ist, Verzeichnisnamen ändern zu können, ohne die Ausführung von Programmen zu beeinträchtigen, die ihre verwenden Arbeitsverzeichnis zum Verweisen auf andere Dateien. Angenommen, Sie haben Wine verwendet, um ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe auszuführen, und Sie wollten stattdessen das gesamte Präfix auf ~/.wine verschieben. Wenn Firefox aus irgendeinem seltsamen Grund auf drive_c/windows zugreift, indem es auf ../../windows verweist, wird ~/.newwineprefix unterbrochen Implementierungen von .., die das übergeordnete Verzeichnis als Textzeichenfolge anstelle eines Inodes verfolgen.

Das Speichern des Inodes eines einzelnen übergeordneten Verzeichnisses muss einfacher sein als der Versuch um jeden Pfad sowohl als Textzeichenfolge als auch als eine Reihe von Inodes zu verfolgen.

Ein weiterer Grund ist dieses Fehlverhalten ng-Anwendungen können möglicherweise Schleifen erstellen. Verhaltende Anwendungen sollten in der Lage sein, zu überprüfen, ob der Inode des zu verschiebenden Verzeichnisses mit dem Inode eines verschachtelten Verzeichnisses übereinstimmt, in das es verschoben wird, genauso wie Sie ein Verzeichnis nicht in sich selbst verschieben können, aber dies wird möglicherweise nicht auf Dateisystemebene erzwungen.

Ein weiterer Grund könnte sein, dass Sie, wenn Sie Verzeichnisse fest verknüpfen könnten, verhindern möchten, dass ein Verzeichnis, das Sie nicht ändern konnten, fest verknüpft wird. find hat Sicherheitsaspekte, da es zum Löschen von Dateien verwendet wird, die von anderen Benutzern aus temporären Verzeichnissen erstellt wurden. Dies kann zu Problemen führen, wenn ein Benutzer während find ruft einen anderen Befehl auf. Wenn wichtige Verzeichnisse fest verknüpft werden können, muss ein Administrator find zusätzliche Tests hinzufügen, um deren Auswirkungen zu vermeiden. (Ok, Sie bereits Dies kann für Dateien nicht durchgeführt werden, daher ist dieser Grund ungültig.)

Ein weiterer Grund ist, dass das Speichern des Inodes des übergeordneten Verzeichnisses zusätzliche Redundanz im Falle einer Beschädigung oder Beschädigung des Dateisystems bieten kann wollte, dass .. alle übergeordneten Verzeichnisse auflistet, die mit diesem verknüpft sind, damit ein anderes, willkürliches übergeordnetes Verzeichnis leicht gefunden werden kann, wenn das aktuelle gelöscht wird. Sie verletzen nicht nur die Idee so stark Links sind gleich, Sie müssen ändern, wie das Dateisystem Inodes speichert und verwendet. Programme behandeln Pfade als eine Reihe (uniq ue auf jeden Hardlink) von Verzeichnis-Inodes würde dies vermeiden, aber Sie würden die Redundanz im Falle einer Beschädigung des Dateisystems nicht erhalten.