Datenverlust in Datei durch Absturz beim Schliessen & schreiben der Config - Wie vermeiden?

Hallo,

in meiner .NET 4.0 WinForms App habe ich mir die Konfigurationsdatei zerschossen, als beim Schließen der App mein System zufällig abgestürzt ist (ich vermute meine Grafikkarte verabschiedet sich langsam).

Beim erneuten Starten der App konnte dann die Konfigurationsdatei nicht mehr eingelesen werden. Ich habe mir die XML-Datei daraufhin in einem Texteditor angeschaut und dann gemerkt, dass die Datei korrupt ist, da sie nur haufenweise "NUL" Einträge enthielt. D.h., sämtliche Konfigurationsdaten sind verloren gegangen.

Um den kompletten Datenverlust bei einem Absturz in Zukunft zu vermeiden, würde ich meinen SettingsProvider folgendermaßen umschreiben:*Beim Beenden der App überprüfen, ob sich etwas an der Konfiguration geändert hat. Falls nein, wird die Konfigurationsdatei nicht neu geschrieben. *Falls sich die Konfiguration geändert hat, soll die Konfiguration zunächst in eine temporäre Datei geschrieben werden, die danach über die Ziel-Datei kopiert wird. (Sollte das System während des Kopiervorgangs abstürzen, so hat man die Daten immerhin noch in der temporären Datei.) Zuletzt wird die temporäre Datei gelöscht.

Was haltet ihr davon? (Datenbanken wie SQLite kommen nicht in Frage, da man die Dateien in einem Texteditor leicht abändern können soll)

Prinzipiell kann das schon funktionieren; mir persönlich würde sich die Frage stellen wie viel Wert diese Umsetzung hat für ein Szenario, das quasi "nie" auftaucht.

Hallo,

wie schreibst du denn die Datei?

Außerdem ist das ein Fall den ich eigentlich nicht genauer betrachten würde. In der Regel stürzt ein Rechner ja nicht genau in dem Moment ab, wo du deine Anwendung beendest.

Ja, klar kannst du analog zu Excel & Konsorten auf einer temporären Kopie arbeiten oder dir sonst eine Lösung ausdenken. Ist alles legitim. Ich möchte aber zu bedenken geben, dass gegen Datenverlust bei Betriebssystem/PC-Crashes nicht die Applikationen was tun sollten, sondern die Backuplösung. Ich mein, das ist genau das, wofür man sowas hat: um Daten wieder herzustellen, die durch einen techn. Fehler verlorengingen.

LaTino

Aber falls das doch mal wieder passiert, in ein paar Jahrzehnten, ist es doch schön wenn man dafür kein Backup bemühen muss.

Für den ersten Schritt reicht es ja die Kopie der Datei zusätzlich zu erstellen. Ohne Prüfung auf den Inhalt. Das dürfte schneller gehen als den Beitrag zu schreiben 😃
Die Prüfung auf Gleichheit, ok nochmal so viel Zeit dazu.

Warum konzentrierst du dich nicht auf die Lösung des eigentlichen Problems (Hardware-Fehler)?

Wenn das Auto klappert fängt man ja auch nicht an, jedwede Fahrbahnunebenheit zu entfernen 😁

@all
Vielen Dank für die Antworten!

@Abt @inflames2k
Dies ist jetzt das erste Mal seit 2 Jahren, dass mir das passiert ist - also so gut wie nie. Trotzdem ist es für mich einmal zu viel. Ich kann das jetzt nicht einfach verdrängen...

@LaTino
Eigentlich sollte es doch die Aufgabe des Dateisystems sein, dafür zu sorgen, dass keine korrupten Daten entstehen können. Aber NTFS unterstützt leider keine Transaktionen. Oder doch?

@chilic
Ja, so sehe ich das auch.

@Sir Rufo
Die neue Grafikkarte liegt schon in der Packstation 😁 Ich hoffe damit läuft mein System wieder stabil.

@LaTino
Eigentlich sollte es doch die Aufgabe des Dateisystems sein, dafür zu sorgen, dass keine korrupten Daten entstehen können. Aber NTFS unterstützt leider keine Transaktionen.
> .

Wth....sorry, aber kommt dir das Argument nicht selbst absurd vor? Dein System ist abgestürzt! Das bedeutet, es konnte sein Aufgaben unvorhergesehenerweise nicht mehr erfüllen. Das ist ja überhaupt der Grund für das defekte File...und kann mit jedem Dateisystem passieren, wenn es unvorhergesehen reagiert (also nicht so arbeitet, wie es soll).

"Mein Betriebssystem hat nicht richtig gearbeitet. Der Fehler wäre nicht aufgetreten, wenn es richtig gearbeitet hätte." Ja, äh, liegt auf der Hand, nicht?

Was chilic vorschlägt, ist ja ein lokales, begrenztes Backup. Kann man machen, wenn man sonst nix zu tun hat 😉

LaTino

Hey, 😃 kommt auch immer auf die Größe der Konfig an, wenn sie mehrere 100 Zeilen besitzt, ist das natürlich blöd, da ist eine Sicherheitskopie wohl nicht schlecht... (wenn man davon absieht wie oft sowas passiert...)

Hallo P.St.,

ich würde auch das Ursprungsproblem beheben. Selbst wenn du eine Lösung für das Abspeichern findest stürzt ja dein Rechner immernoch ab (So wie ich das verstanden habe). Völlig unabhängig von der gerade laufenden Software.

Es gibt ja auch - Gott sei Dank selten - Stromausfälle. Also bräuchtest du auch eine USV etc.

Widme dich dem PC Problem und behebe das. Das ist sicher zielführender.

Gruss

Coffeebean

Hallo zusammen,

ein ähnliches Problem ist mir auch bekannt. Und zwar verwendet ein Kunde PC´s mit Akkubetrieb.
Wird der PC heruntergefahren, ist die letzte Aktion der Software, den "Schalter" umzulegen. Also den Strom zu trennen.
Das hat zu selbigem Verhalten geführt. Die Applikation bekommt vom OS die Aufforderung sich zu beenden, aber nicht mehr die Zeit die Konfig bis zum Ende zu schreiben.
Dort hatte ich regelmäßig das Problem.

Lösung war, dass ich meinen Serializer um ein "Modified"-Property ergänzt habe, welches sich bei jedem INotifyPropertyChanged.Notify() auf true und jedem Save() auf false gesetzt hat.
Somit wurden die Settings nur noch gespeichert, wenn sie mussten und nicht mehr bei jedem Programm-Ende.

Dabei noch eine zweite Datei parallel zu erstellen und im Falle eines Fehlers beim Deserialisieren zu laden, finde ich eigentlich auch recht charmant.

Neben Abstürzen und Stromausfällen ist mir noch ein weiteres Szenario eingefallen. Da es sich um eine portable App handelt kann die App z.B. auf einem USB-Stick ausgeführt werden. Zieht der Nutzer beim Beenden der App den Stick vorzeitig heraus, haben wir dasselbe Problem.

Ich habe nun die Speicherlogik in etwa wie oben beschrieben implementiert. "Getestet" habe ich es mit einem alten, schön langsamen USB-Stick (128 MByte), den ich mehrfach beim Schreiben gezogen habe. In jedem Test war eine der beiden Dateien noch in Ordnung. Die Sache hat sich für mich damit erledigt.