Warum sind feste Links nur innerhalb desselben Dateisystems gültig?

22

Ich lese dieses Intro in der Kommandozeile von Mark Bates.

Im ersten Kapitel erwähnt er, dass Hardlinks keine Dateisysteme umfassen können.

Bei Hardlinks ist zu beachten, dass sie nur auf dem aktuellen Dateisystem funktionieren. Sie können keine feste Verknüpfung zu einer Datei in einem anderen Dateisystem erstellen. Dazu müssen Sie symbolische Links verwenden, Abschnitt 1.4.3.

Ich kenne nur ein Dateisystem. Derjenige, der mit root ( /) beginnt . Diese Aussage, dass harte Links sich nicht über Dateisysteme erstrecken können, macht für mich keinen Sinn.

Der Wikipedia- Artikel zu Unix-Dateisystemen ist ebenfalls nicht hilfreich.

filesystems hard-link

— Anton Paras
quelle

29

Hoffentlich kann ich das so beantworten, dass es für Sie Sinn macht. Ein Dateisystem unter Linux besteht im Allgemeinen aus einer Partition, die auf eine der folgenden Arten formatiert ist (das muss man sich aussuchen!), Auf der Sie Ihre Dateien speichern. Sei es Ihre Systemdateien oder Ihre persönlichen Dateien ... alle werden auf einem Dateisystem gespeichert. Diesen Teil scheinen Sie zu verstehen.

Aber was ist, wenn Sie Ihre Festplatte so partitionieren, dass mehr als eine Partition vorhanden ist (denken Sie, Apple Pie ist in Stücke geschnitten), oder eine zusätzliche Festplatte hinzufügen (möglicherweise einen USB-Stick?). Aus Gründen der Argumentation haben alle auch Dateisysteme.

Wenn Sie sich die Dateien auf Ihrem Computer ansehen, sehen Sie eine visuelle Darstellung der Daten im Dateisystem Ihrer Partition. Jeder Dateiname entspricht einer sogenannten Inode, in der Ihre Daten im Hintergrund wirklich leben. Ein fester Link lässt Sie mehrere "Dateinamen" (mangels einer besseren Beschreibung) haben, die auf denselben Inode verweisen. Dies funktioniert nur, wenn sich diese festen Links im selben Dateisystem befinden. Eine symbolische Verknüpfung verweist stattdessen auf den "Dateinamen", der dann mit dem Inode verknüpft ist, der Ihre Daten enthält. Verzeihen Sie meine rohen Kunstwerke, aber das erklärt sich hoffentlich besser.

image.jpg             image2.jpg
          \           /
           [your data]

Hier verweisen image.jpg und image2.jpg direkt auf Ihre Daten. Sie sind beide Hardlinks. Jedoch...

image.jpg    <-----------  image2.jpg
           \ 
             [your data]

In diesem (groben) Beispiel verweist die Datei image2.jpg nicht auf Ihre Daten, sondern auf die Datei image.jpg ..., die einen Link zu Ihren Daten darstellt.

Symbolische Links können über Dateisystemgrenzen hinweg funktionieren (vorausgesetzt, das Dateisystem ist wie Ihr USB-Stick angehängt und gemountet). Ein fester Link kann dies jedoch nicht. Es weiß nichts darüber, was sich auf Ihrem anderen Dateisystem befindet oder wo Ihre Daten dort gespeichert sind.

Hoffentlich ergibt das einen besseren Sinn.

— Dubkat
quelle

Vielen Dank. Ich wusste nicht, dass verschiedene Dateipartitionen "Dateisysteme" genannt werden.

— Anton Paras

1

Eines der Dinge, die Sie mit einer Partition tun können, ist, ein Dateisystem darauf abzulegen. Es gibt andere Orte, an denen Sie Dateisysteme ablegen können, und andere Dinge, die Sie mit Partitionen tun können. Die häufigste Option ist jedoch diese.

— Jasen

10

Es gibt eine Dateihierarchie , die bei "/" beginnt. Es werden ein oder mehrere Dateisysteme gemountet

— mpez0

@ mpez0: Nicht einmal, mit zB chroot(2)oder realer Containerisierung können Sie mehrere Hierarchien haben, die möglicherweise überhaupt nichts miteinander zu tun haben.

— Kevin

@Kevin, chrootisoliert einen Teil der Hierarchie für einen Prozess und seine Nachkommen, der übergeordnete Teil verfügt jedoch weiterhin über eine vollständige Hierarchie. Die Containerisierung kann dies tun, je nachdem, wie nah eine VM ist. Aber wie viel Detail kann man in einen Kommentar packen? Danke,

— mpez0

23

Das Dateisystem besteht aus einer Verzeichnisstruktur für Verzeichniseinträge zum Organisieren von Dateien. Jeder Verzeichniseintrag ordnet einem Inode einen Dateinamen zu .

Softlinks ( symbolisch ) sind Verzeichniseinträge, die keine Daten enthalten. Sie verweisen lediglich auf einen anderen Eintrag (eine Datei oder ein Verzeichnis im selben Dateisystem oder einem anderen Dateisystem). Und wenn Sie die angezeigte Datei löschen, wird die symbolische Verknüpfung unbrauchbar.

Hardlinks sind Verzeichniseinträge, die den Dateinamen und die Inode- Nummer enthalten. Wenn Sie den letzten festen Link entfernen, können Sie nicht mehr auf die Datei zugreifen.

Fazit:

Da der Inode eine Datenstruktur ist, die zur Darstellung eines Dateisystemobjekts verwendet wird, ist sie im Dateisystem intern und Sie können nicht auf einen Inode verweisen eines anderen Dateisystems .

Somit sind Hardlinks nur innerhalb desselben Dateisystems gültig, aber Softlinks (symbolische Links) können sich über Dateisysteme erstrecken, da sie einfach auf einen anderen Verzeichniseintrag verweisen (Die Schnittstelle des Dateisystems und kein internes Objekt).

— Facundo Victor
quelle

1

Schöne prägnante Antwort.

— Dubkat

Was passiert, wenn ein anderes Dateisystem (zum Beispiel USB) eine Datei mit demselben NAMEN hat, mit dem unser symbolischer Link in unserem Dateisystem verbunden ist?

— Josef Klimuk

@JosefKlimuk, ein Softlink würde auf einen Pfad verweisen, sagen wir mal /mnt/myfile. Wenn Sie ein anderes Dateisystem anhängen /mnt/. Der Softlink würde zu einem Eintrag des gemounteten Dateisystems unter aufgelöst /mnt/. Wenn Sie also das Dateisystem von Ihrem USB-Gerät aus anhängen /mnt, wird der Softlink zu einem Eintrag in diesem Dateisystem aufgelöst.

— Facundo Victor

2

Das Root-Dateisystem kann aus mehreren Dateisystemen bestehen. /usr/localbefindet sich möglicherweise auf einer separaten Partition und /homeauf einer anderen Partition auf einer Netzwerkfestplatte an einem anderen Ort. In diesem Fall kann ein fester Link für /usr/local/bin/git(zum Beispiel) nicht außerhalb von erstellt werden /usr/local, da er sich über Dateisysteme erstrecken würde .

Der Grund dafür ist , dass der I - Knoten separat für zugeordnet ist /, /usr/localund /home(wieder, in diesem Beispiel), und wenn Sie eine feste Verknüpfung erstellen Sie wirklich nur einen zusätzlichen Namen für einen Inode machen.

— Kusalananda
quelle

2

Harte Links bewirken, dass das Ziel am Leben bleibt. Solange ein fester Link erreichbar ist, stellt das System sicher, dass sein Ziel nicht freigegeben wird. Es ist daher erforderlich, dass alle Medien, die feste Verknüpfungen zu einem bestimmten Inode enthalten könnten, jedes Mal gemountet werden, wenn das System versuchen würde, festzustellen, ob Verweise darauf vorhanden sind.

Angesichts der Tatsache, dass die Inode-Lebensdauer in der Regel durch Aufrechterhaltung der Referenzanzahl und nicht durch Suchen nach Referenzen bestimmt wird, können möglicherweise zwei oder mehr Dateisysteme, die über Links miteinander verbunden sind, unabhängig voneinander verwendet werden, vorausgesetzt, dass keine Links verwendet werden müssen überbrückt zwischen den Systemen und vorausgesetzt, es war nicht erforderlich, fsck auf einem der beiden zu verwenden. Wenn die Anzahl der Inodes auf einem der Systeme gestört ist, besteht die einzige Möglichkeit, dieses System wieder nutzbar zu machen, darin, eine Form der fsck-Operation zu verwenden, mit der beide Dateisysteme nach Verweisen durchsucht werden können. Aufgrund dieser Einschränkung ist es zwar möglich, zwei miteinander verknüpfte Dateisysteme unabhängig voneinander verwenden zu können, die Vorteile wären jedoch wahrscheinlich zu gering, um dies sinnvoll zu machen.

— Superkatze
quelle

Guter Punkt, aber ein bisschen zu tangential, um eine gute Antwort zu geben.

— Joe

@Joe: Das Zulassen fester Verbindungen zu dateisystemübergreifenden Systemen würde eine Reihe technischer Schwierigkeiten mit sich bringen, die meisten könnten jedoch überwunden werden, was die Frage aufwirft, ob es einen zwingenden Grund gibt, warum dies nicht der Fall sein sollte. Das Keep-Alive-Problem mag dunkel erscheinen, aber im Gegensatz zu den anderen Problemen kann es nur von mir gelöst werden, indem der Verwendung solcher Links strenge semantische Einschränkungen auferlegt werden, die deren Wert erheblich einschränken würden.

— Supercat

Guter Punkt. Ein Dateisystem kann auf einem anderen Gerät eingehängt und geändert werden, sodass Inode und Links möglicherweise nicht mehr synchron sind. Jedes Dateisystem könnte eine GUID haben und der Link könnte diese GUID enthalten, um den Inode zwischen Dateisystemen zu verfolgen. Es könnte auch eine Art Protokoll auf dem FS geben, und wenn es eingehängt ist, müsste das Hostsystem es nicht scannen, sondern könnte nur das Protokoll lesen und die Änderungen an den Inode-Verknüpfungen "nachholen" (Wann löschen wir es, obwohl?). Unterm Strich müsste der zugrunde liegende FS auf nicht triviale Weise geändert werden und würde nur auf kompatiblen Dateisystemen funktionieren.

— Rolf

1

Eine einzelne Inode- Nummer zur Darstellung der Datei in jedem Dateisystem. Alle Hardlinks basieren auf der Inode-Nummer. Dateisystem-Referenzlink hier .

— msc
quelle