Atomic schreibt - wie tempfile + os.replace beschädigte JSON verhindern

Was passiert, wenn der Strom ausfällt, während ein Prozess in eine Konfigurationsdatei schreibt? Oder wenn Antiviren-Software unter Windows kurzzeitig eine Datei mitten im Schreiben sperrt? Wenn Sie eine Datei naiv überschreiben, bleibt der teilweise Inhalt, der zum Zeitpunkt der Unterbrechung existiert, auf der Festplatte. Für JSON bedeutet das in der Regel eine defekte Syntax - wirft das nächste Startup auf und die gesamte Konfiguration geht effektiv verloren. Dieser Artikel geht durch eine Standardtechnik, um das zu verhindern: zuerst in eine temporäre Datei schreiben und dann atomar austauschen. Hinweis: "Atom" bedeutet hier, dass eine Operation entweder vollständig abgeschlossen ist oder überhaupt nicht stattfindet - es gibt keinen teilweisen, beobachtbaren Zwischenzustand. Es ist der gleiche Sinn des Wortes, das für Datenbanktransaktionen verwendet wird. Warum direkte Überschreibungen gefährlich sind, verkürzt effektiv die Datei zuerst und schreibt dann den neuen Inhalt. Wenn der Prozess während dieses Fensters unterbrochen wird, bleibt die Datei leer oder enthält unvollständigen Inhalt. Die Ursachen variieren: a, ein Stromausfall, Antivirensoftware, die den Dateizugriff unter Windows kurzzeitig blockiert, oder ein Backup-Tool, das die Datei mitten im Schreiben erfasst. Dies reproduziert sich selten während der lokalen Entwicklung, aber in einer langjährigen Produktionsumgebung wird es schließlich mit nahezuer Sicherheit passieren. Der Fix: Schreiben Sie in eine Temp-Datei und tauschen Sie sie in Die Kernidee ist einfach. Berühren Sie niemals die Zieldatei direkt. Schreiben Sie zuerst den vollständigen neuen Inhalt in eine temporäre Datei, bestätigen Sie, dass das Schreiben vollständig gelungen ist, und ersetzen Sie erst dann die Zieldatei durch diese Temp-Datei. erzeugt einen kollisionsfreien temporären Dateinamen und gibt seinen Dateideskriptor zurück. Das Argument ist hier wichtig: Das Platzieren der Temp-Datei im selben Verzeichnis wie die Zieldatei stellt sicher, dass der folgende Aufruf in einem einzigen Dateisystem bleibt. Warum ist atomar Der Kern dieses Musters ist der letzte Aufruf. Pythons offizielle Dokumentation besagt, dass "eine atomare Operation unter Unix sein wird" und sich auch unter Windows atomar verhält, solange sich beide Pfade auf demselben Dateisystem befinden. Auf POSIX-Systemen (Linux/macOS) wird dieser dem Systemaufruf zugeordnet. Auf der Kernelebene ist das Tauschen eines Verzeichniseintrags eine einzige unteilbare Operation. Es gibt keinen Zwischenzustand zu beobachten - von außen ist die Datei entweder in ihrem Pre-Swap- oder Post-Swap-Zustand, niemals etwas dazwischen. Unter Windows implementiert Python 3.3+ dies so, dass das Überschreiben einer vorhandenen Datei atomar gehandhabt wird (was ungefähr dem Aufruf mit dem Flag entspricht). Dank dieser Eigenschaft, wenn der Prozess in der Mitte von stirbt, ist nur die ungenannte Temp-Datei betroffen - die echte Konfigurationsdatei bleibt unberührt, in welchem gültigen Zustand sie sich zuvor befand. Selbst mit einem Atom gibt es ein subtileres Risiko: Der Inhalt, von dem geschrieben wurde, befindet sich möglicherweise immer noch im Cache der Betriebssystemseite und nicht physisch auf der Festplatte, wenn Strom verloren geht. In diesem Fall könnte der Umname selbst abgeschlossen werden, aber der Inhalt der umbenannten Datei spiegelt möglicherweise nicht wider, was tatsächlich geschrieben wurde. adressiert dies. Drückt Pythons internen Puffer nur ins Betriebssystem - er befindet sich möglicherweise noch im Cache auf Betriebssystemebene. geht noch einen Schritt weiter und fordert das Betriebssystem auf, zu warten, bis die Daten tatsächlich auf die physische Festplatte geschrieben sind. Die Kombination beider Schritte stellt sicher, dass der Inhalt der Temp-Datei dauerhaft auf der Festplatte ist, wenn die Zeit läuft. Aufräumen nach einem fehlgeschlagenen Schreiben Wenn das Schreiben in die Temp-Datei selbst teilweise fehlschlägt (Festplatte voll, Berechtigungsfehler usw.), wird nie erreicht, so dass die Zieldatei nicht betroffen ist. Aber die halb geschriebene Temp-Datei bleibt auf der Festplatte zurück. Ohne Aufsicht sammeln sich diese als Unordnung an, daher lohnt es sich, sie beim Scheitern explizit zu löschen. Die verschachtelten Konten für die Möglichkeit, die selbst fehlschlägt (bereits gelöscht, keine Erlaubnis, etc.). Das erneute Anheben der ursprünglichen Ausnahme () stellt sicher, dass der Anrufer immer noch erfährt, dass das Schreiben fehlgeschlagen ist. Schutz vor übrig gebliebenen Dateien Da der Temp-Dateiname verbraucht und bei Erfolg in den Zielnamen getauscht wird, bleiben Dateien normalerweise nicht im regulären Betrieb. Aber in einem extremen Edge-Fall - der Prozess wird 'd im engen Fenster direkt nach der Temp-Datei vollständig geschrieben, aber