Wie funktioniert Linux mit symbolischen Links?

Ich meine, was ist los, wenn ein Prozess einen Symlink lesen möchte? Was ist los, wenn etwas einen Symlink während eines Lese- oder Schreibvorgangs ändert?

Zum Beispiel: Ich habe 2 riesige, ähnliche 100G-Dateien /mnt/1und /mnt/2. /mnt/1ist über den Symlink verfügbar /home/user/file. Einige Programme Abeginnen zu lesen /home/user/file. Und nach einer Weile ändert etwas den Link von /mnt/1zu /mnt/2, Aliest aber immer noch die Datei.

Zwischenspeichert das Programm den absoluten Pfad?

Wird es fehlschlagen und fehlerhaft sein, weil der Symlink geändert wurde, oder wird es gut funktionieren, als wäre nichts passiert?

Wird es anders sein, wenn /home/user/filees mit einem Blockgerät verbunden ist (zum Beispiel 2 replizierte iscsi-Festplatten)?

Der Symlink zeigt auf den Namen der realen Datei ( Inode ) im Dateisystem. Wenn das System diesen Symlink auflöst, um die eigentliche Datei zu finden und zu öffnen, findet und verwendet es den Inode der Datei. An diesem Punkt spielt der Pfad, den Sie verwendet haben, um zur Datei zu gelangen, keine Rolle. Was das Betriebssystem nicht zwischenspeichert, liest es aus der Datei durch seinen Inode. Soweit ich weiß, können Sie die Datei über einen festen Link lesen und diesen festen Link entfernen (solange die Datei noch von einem anderen Ort aus verknüpft ist) . Dies würde keine Probleme verursachen, solange die Datei aufgelöst wurde ( Name string-> inode).

Ein symbolischer Link ist eine kleine Datei, die den Speicherort (dh Pfad und Dateiname) einer Zieldatei enthält, wobei ein Flag im Verzeichniseintrag angibt, dass es sich um einen Symlink handelt.

Wenn Sie einen Symlink öffnen, folgt das Betriebssystem dem Speicherort, um die Zieldatei zu finden. Wenn das Ziel selbst ein Symlink ist, folgt es auch seinem Speicherort (1) (2), bis der Speicherort auf eine Datei verweist, die kein Symlink ist (nennen wir sie FinalFile ). Dann erhält das Betriebssystem den Inode der FinalFile (der Inode enthält Metadaten wie die Änderungszeit und hat auch einen Zeiger auf die Daten der Datei). Schließlich wird der Inode der FinalFile geöffnet. Von nun an verwendet der Prozess diesen Inode zum Lesen / Schreiben in die Datei. Infolgedessen ändern Sie den Symlink-Namen oder -Pfad, löschen den Symlink, ändern den Pfad oder den Namen der FinalFile oder löschen sogar die FinalFile(3) hat keine Auswirkung auf den Prozess; Es liest immer noch von derselben Inode.

In den meisten Fällen wirken sich Dateidatenoperationen auf dem Symlink auf die FinalFile aus (z. B. wird beim Lesen und Schreiben in den Symlink aus der FinalFile gelesen / in diese geschrieben ), es gibt jedoch Ausnahmen: Der readlink()Systemaufruf liest den Inhalt des Symlinks selbst.

Dateimetadatenoperationen (wie Umbenennen oder Löschen) wirken sich normalerweise auf den Symlink aus. Aber auch hier gibt es Ausnahmen: Der lstat()Systemaufruf ist wie folgt stat(), außer dass er Informationen über den Symlink selbst und nicht über FinalFile (2) zurückgibt .

(1) Die Anzahl der Ebenen ist begrenzt, und die Dinge werden etwas komplexer, wenn die Position im Symlink ein relativer Pfad ist.

(2) Symlink lesen (7): Symbolische Linkbehandlung für weitere Details.man 7 symlink

(3) Der rmBefehl oder der unlink()Systemaufruf entfernt eine Datei nicht physisch. Es entfernt den Verzeichniseintrag, der auf den Inode der Datei verweist. Die Datei selbst wird nur entfernt, wenn sowohl a) keine Verzeichniseinträge (Hardlinks) mehr vorhanden sind, die auf ihren Inode verweisen, als auch b) kein Prozess die Datei geöffnet hat.

Das ist für Linux fast transparent und hängt viel mehr mit dem von Ihnen verwendeten Dateisystem zusammen als mit dem Betriebssystem.

Es handelt sich nicht um eine reguläre oder eine sehr kleine Datei, da Sie in einer VFAT-Partition keine funktionierende symbolische Verknüpfung erstellen können, indem Sie beispielsweise nur die symbolische Verknüpfung selbst darauf kopieren, da sie direkt vom Dateisystem aufgezeichnet wird.

Der Unterschied in der symbolischen Verknüpfung zu einer festen Verbindung besteht darin, dass die Ernennung zu einer festen Verbindung erfolgt, anstatt wie bei einer festen Verbindung zu den Datensektoren zu wechseln.

Beispiel:

Test 1:

echo 'data' >file.txt

Dadurch wird die Hardlink-Datei file.txt erstellt, die auf die Sektoren 10 bis 20 * verweist (* Zahlen nur zur Erläuterung).

Test 2:

Was wäre wenn?

ln file.txt file_2.txt

Dadurch wurde ein Hardlink file_2.txt erstellt, der auf die Sektoren 10 bis 20 verweist (dasselbe wie file.txt). Wenn Sie also file.txt löschen, sind die Sektoren 10 bis 20 weiterhin reserviert und Sie können Daten in file_2.txt sehen ... . (file.txt und file_2.txt sind beide wie die Originale)

Test 3:

ln -s file.txt file_sym.txt 

Der symbolische Link file_sym.txt auf den festen Link file.txt wurde angezeigt. Wenn Sie also versuchen, auf file_sym.txt zuzugreifen, wird file.txt angezeigt. Wenn Sie jedoch file.txt löschen, findet file_sym das Ziel nicht mehr.

Diese werden vom Dateisystem verwaltet, beispielsweise von den ext4-Modulen für Linux (oder wenn es auf dem Kernel kompiliert wird). Es spielt keine Rolle, ob Sie Linux oder ein anderes Unix verwenden.