Warum kann ich eine Datei unter Linux erfolgreich verschieben, während sie geschrieben wird?

Question

Diese Frage denke ich ist technisch genug für S/O, und wahrscheinlich auch zu programmieren-orientierte für Android. Ich bin fasziniert, wie Dateien in Android (oder Java oder Linux, wie angemessen) gehandhabt werden, da ich etwas mit meinem neuen Smartphone gemacht habe und ich würde gerne wissen, wie es passiert ist.

Ich habe eine Datei von meinem Laptop auf mein Android-Handy über Bluetooth übertragen. Ich habe die neue Datei im Dateiexplorer gesehen, angenommen, dass sie vollständig übertragen wurde, und sie so von /sdcard/bluetooth zu /sdcard/torrents verschoben. Nachdem ich das getan hatte, bemerkte ich, dass es tatsächlich noch übertragen wurde. Zu meiner Überraschung wurde es erfolgreich abgeschlossen, bestätigt mit einem Benachrichtigungssymbol im Telefon und durch eine manuelle MD5-Überprüfung auf beiden Seiten. In den meisten Systemen hätte die Dateiverschiebung einen Absturz verursacht.

Was ist der Grund für diese erfolgreiche Übertragung? Mir ist bekannt, dass der Dateipfad im Allgemeinen vom Dateispeicherort im Dateisystem (in diesem Fall eine SD-Karte) getrennt ist. Ich stelle mir vor, dass die Bluetooth-App ein Handle für die Datei geöffnet hat, und als ich die Datei verschoben habe, wurde eine Tabelle mit "geöffneten Dateien" mit einem neuen Pfad aktualisiert. Gilt diese Funktion generell für jedes Linux-System? Könnte ich eine mv für eine Datei schreiben und erwarten, dass die Kopie - an ihrem neuen Speicherort - korrekt ist?

Answer 1

Wenn Sie eine Datei im gleichen Filesystem bewegen, die Datei selbst (die inode) wird nicht bewegt. Das einzige, was sich ändert, sind die Verzeichniseinträge in diesem Dateisystem. (Der Systemaufruf von mv in diesem Fall in Anspruch genommen ist rename(2) - überprüfen Sie die Seite für zusätzliche Informationen und Einschränkungen.)

Wenn ein Prozess eine Datei öffnet, wird der Dateiname an das OS übergeben, um anzuzeigen, welche Datei gemeint ist, aber die Datei-Deskriptor, den Sie zurückbekommen, ist überhaupt nicht mit diesem Namen verbunden (Sie können keinen Dateinamen von ihm zurückbekommen) – es ist mit dem Inode verbunden.
Da der Inode beim Umbenennen einer Datei (innerhalb desselben Dateisystems) unverändert bleibt, können Prozesse, die ihn geöffnet haben, problemlos weiterlesen und darauf schreiben – hat sich für sie nichts geändert, ihr Dateideskriptor ist immer noch gültig und zeigt nach rechts Daten.

Das Gleiche, wenn Sie eine Datei löschen. Prozesse können weiterhin lesen und schreiben, selbst wenn die Datei nicht mehr über einen Verzeichniseintrag erreichbar ist. (Dies kann zu verwirrenden Situationen führen, in denen df meldet, dass Ihr Datenträger voll ist, aber du sagt, dass Sie viel weniger Speicherplatz verwenden, den df meldet. Die Blöcke, die gelöschten Dateien zugewiesen sind, die noch geöffnet sind, werden nicht freigegeben, bis diese Prozesse ihre schließen Dateideskriptor.)

Wenn die mv die Datei über Dateisysteme verschiebt, ist das Verhalten anders, da Inodes für jedes Dateisystem spezifisch sind. In diesem Fall kopiert mv die Daten tatsächlich und erstellt einen neuen Inode (und Verzeichniseintrag) auf dem Zieldateisystem. Wenn die Kopie beendet ist, wird die alte Datei entkoppelt und entfernt, wenn keine offenen Dateihandles darauf sind, wie oben.
In Ihrem Fall, wenn Sie eine Dateisystemgrenze überschritten haben, haben Sie eine Teildatei im Ziel. Und Ihr Upload-Prozess schreibt glücklich in eine gelöschte Datei, auf die Sie nicht einfach zugreifen können, und füllt möglicherweise das Dateisystem auf, bis der Upload abgeschlossen ist und der Inode dann fallen gelassen wird.

Einige Beiträge über Unix & Linux, die Sie interessant finden könnte:

• How are directories implemented in Unix filesystems?
• What is a Superblock, Inode, Dentry and a File?