Textfile nach Stromausfall leer

[eskimo328]

Hi zusammen
ab und zu tritt bei den Nutzern unserer Anwendung folgendes Problem auf:

1. Ein Datentransfer wird gestartet, d.h. Daten werden aus dem Hauptsystem vom Server geladen und die Objekte serialisiert (als .ser Datei gespeichert)
2. In einer Textdatei/Properydatei wird eine Property "issaving=1" geschrieben, mittels der Methode, siehe unten.
3. Objekte werden deserialisiert und Daten entsprechend in lokaler H2-Datenbank gespeichert.

Beim letzten Schritt geht der Akku des Notebooks leer und das Noteook geht aus, weil kein Nezteil eingesteckt ist.
Der nächste Start der Anwendung schlägt fehl, weil die Propertydatei leer ist.
Wie kann es sein, dass nach einem Stromausfall nichts mehr in der Datei drin steht?

Das ist die Methode um die Werte in der Propertiesdatei zu speichern:

public void setProperty(String key, String value) {    	
        this.globalProperties.setProperty(key, value);
    	
    	FileOutputStream fos = null; 
        
        try {
        	fos = new FileOutputStream(this.iniFile);
			this.globalProperties.store(fos, "");
			
			Logger.log("Stored property: "+key+"="+value, this);
		} 
        catch (FileNotFoundException e) {
        	Logger.printStackTrace(e, this);
		}
        catch (IOException e) {
			Logger.printStackTrace(e, this);
		}
        finally {
        	IOUtils.close(fos);
        }
    }

 

[SlaterB]

du redest so abstrakt von Stromausfall und 'kann das sein', immerhin auch von entfernten Nutzern,
hast du es lokal selber getestet? direkt nach Ausführung der Methode muss die Datei doch vorhanden sein
mit korrekten Inhalt oder tatsächlich anders beobachtet?

im Programm könnte es eine zweite Methode geben, die einliest als Gegencheck,
gibt es wenigstens ein Log, welches bis zum Ausfall klaglos funktioniert und diese Information aufnehmen könnte?

problematisch ist hier in engen Grenzen, dass immer wieder in dieselbe Datei geschrieben wird, direkt beim Schreibvorgang
wird die Datei immer erst auf leer gesetzt, dann mit Inhalt befüllt,
das könnte mit mehreren Dateinamen besser behandelt werden,

 

[eskimo328]

Ich konnte das Problem vorhin 2 Mal reproduzieren. Also Akku entfernen und Notebook nur mit Netzteil starten. Dann die Anwendung und die entsprechende Verarbeitung starten, bei der das Problem auftritt. Während der Verarbeitung habe ich dann den Stecker gezogen.

Der Log-Eintrag "Stored property: isSaving=1" ist vorhanden. Danach kommen noch zwei weitere Log-Einträge und dann hört die Log auf. Daher gehe ich von aus, das die Property auch korrekt gesetzt wurde und die Property in der File gespeichert wurde. Ansonsten müsste eine Exception geloggt worden sein.

Wieso mit mehreren Dateinamen, das ist mir nicht ganz klar, wie meinst du das?

 

[SlaterB]

> wie meinst du das?
ich verstehe nicht was du nicht verstehst, wie meinst du das?

ein rotes Tuch für mich, der Kahlschlag jeder Diskussion, zumindest wenn schon Text dasteht,
ich möchte nicht alles beliebig neuformulieren, es steht schon einiges da, schreibe wenigstens was du jeweils verstehst oder nicht,
wenn es um eine 'leere Datei' als Grundproblem geht und ich u.a. von "direkt beim Schreibvorgang wird die Datei immer erst auf leer gesetzt" spreche, kann ich pauschales 'häh' nicht akzeptieren 😉
(ich hatte es vorher noch drastischer formuliert, ist schon entschäfte Version 😉 )

aber egal, nach deiner Beschreibung geht es ja sowieso nicht um Abbruch direkt beim Schreiben

--------

> Der Log-Eintrag "Stored property: isSaving=1" ist vorhanden. Danach kommen noch zwei weitere Log-Einträge und dann hört die Log auf.

wieviel ist das denn in Zeit, sitzt du währenddessen am Gerät und hast du die Datei geprüft?
muss aber nicht sein, wie gesagt, Vorschlag: "im Programm könnte es eine zweite Methode geben, die einliest als Gegencheck,"

wenn dieser Check positiv ist und auch Logeintrag dazu, dann kann man die Datei ja wohl als vorhanden annehmen,
falls keine Zeit für diesen Check bleibt, dann war sowieso insgesamt reichlich knapp

sollte es gar positiven Check geben und immer noch falsche Datei? das wäre dann etwas heftiger

-----

freilich sollte es auch direkt gehen,
einen Mini-Hinweis habe ich noch, dass die Log-Ausgabe in diesem speziellen Problemfall vielleicht zur erhöhten Sicherheit lieber erst nach dem close() stattfinden sollte,

aber 'eigentlich' müsste es auch direkt funktionieren, Properties.store() hat ein flush() eingebaut,
was mich zur Einsicht bringt, dass ich anscheinend bisher nicht viel beitragen kann, da passt mein obiges Gepolter besonders wenig 😉
naja, immerhin hast du paar zusätzliche Informationen geschrieben

 

[Lumaraf]

Die Änderungen an der Datei werden erstmal nur in die Caches vom Betriebssystem geschrieben. Es kann ein paar Sekunden dauern bis die Daten auch tatsächlich auf die Festplatte geschrieben werden.

Füg mal vor dem schließen noch ein

fos.getFD().sync();

ein, das erzwingt das schreiben auf die Festplatte.

 

[Gast2]

Wieso mit mehreren Dateinamen, das ist mir nicht ganz klar, wie meinst du das?

1. write new
2. move current old
3. move new current
4. delete old

egal wann das BS aus geht, du hast immer einen funktionierenden Stand aller Properties

hand, mogel