Ini-Inhalt geht in sehr seltenen Fällen verloren (TMemIniFile)

[Bjoerk]

TMemIniFile ist nicht von TIniFile abgeleitet (beide von TCustomInifile). Beim Freigeben von TMemIniFile wird definitiv nicht UpdateFile aufgerufen. Jedenfalls ist das so bis D2007.

[CodeX]

Zitat von Bjoerk:

Beim Freigeben von TMemIniFile wird definitiv nicht UpdateFile aufgerufen.

Ihr habt in dem Punkt recht, sorry.
Ich setze wie gesagt eine von TMemIniFile abgeleitete Variante ein, wo ich vor langer Zeit den Destructor entsprechend angepasst habe, dass ein Free das UpdateFile auslöst, damit man es nicht jedes Mal selbst ausführen muss. Ich nutze das so selbstverständlich, dass ich tatsächlich vergessen hatte, dass dies normalerweise nicht geschieht. Meine Variante hatte ich übrigens vor ein paar Jahren hier mal vorgestellt (MemIniCrypt: Vollverschlüsseltes Arbeiten mit ini-Dateien).

Selbstverständlich arbeite ich nicht mit einer globalen Ini-Datei, sondern erzeuge sie punktuell und gebe sie auch direkt wieder frei, da wo was gelesen/gespeichert wird.

Beim manuellen Beenden werden ein paar Programmeigenschaften gespeichert (Position, Größe, Ansicht, etc.). Das braucht nicht bei jedem Verschieben eines Fensters gespeichert zu werden. Ich habe allerdings darauf geachtet, dass dies nur beim manuellen Beenden geschieht, nicht jedoch beim Herunterfahren. Ich habe das heute nochmal mit einem ausführlichen Log überprüft.

Allerdings rede ich von Anfang an ja von unerwartetem Beenden. Dabei können in der Anwendung aktive Objekte (ggf. in eigenen Threads) auf die Ini-Datei (schreibend) zugreifen während das Herunterfahren oder ein Windowsabsturz geschieht. Darüber hat die Anwendung keinen Einfluss. Wäre es eine häufige Konstellation, würde ich eine ganz andere Lösung suchen. Aber es passiert in einem von vielen tausend Fällen. Das klingt wenig, aber das ist für genau den Anwender auch schon zu viel, da es keine kleine Fehlermeldung ist, sondern die gesamte Arbeit vernichtet.

Ich suche eine Lösung, damit dieser Fall generell nicht mehr passieren kann. Also sowas wie "ganz oder gar nicht" bzw. "erst schreiben, dann löschen". Aber die manuellen Lösungen, die mir dazu einfallen, laufen auf das Führen von 2 Ini-Dateien hinaus, wo bei jedem Schreibvorgang der Inhalt der einen in die andere geschrieben wird, bevor der Inhalt der ersten gelöscht wird. Aber das klingt für mich nicht sehr performant, was natürlich insbesondere dadurch blöd ist, da es für die meisten Fälle/Anwender noch nie relevant war oder sein wird.

Meine Hoffnung war, dass sich darüber jemand schon mal ausführlich Gedanken gemacht hat und irgendetwas implementiert hat, das dies auf elegante Weise löst. Oder eben einen konkreten Hinweis, wie man das angehen könnte (bzw. irgendwelche Windowsmechanismen dafür nutzen könnte).

Edit: Oder das Problem hat mit dem Schreibvorgang in UpdateFile gar nichts zu tun, sondern hat einen ganz anderen Grund. Ersteres ist ja nur eine theoretische Vermutung, die sich nicht so einfach bzw. schnell überprüfen lässt. Ggf. sowas wie das was himitsu gesagt hat...

[Uwe Raabe]

Du kannst in deiner Ableitung von TMemIniFile das UpdateFile überschreiben. Dort benennst du die aktuelle Ini-Datei um, z.B. in <wasauchimmer>.sav, rufst dann das inherited auf und wenn das sauber zurück kommt, kannst du die sav-Datei löschen.

Beim Create schaust du, ob die INI-Datei existiert (und vielleicht noch, ob sie nicht leer ist). Andernfalls suchst du nach einer sav-Datei und benennst die wieder in .ini um.

[CodeX]

Zitat von Uwe Raabe:

Du kannst in deiner Ableitung von TMemIniFile das UpdateFile überschreiben. Dort benennst du die aktuelle Ini-Datei um, z.B. in <wasauchimmer>.sav, rufst dann das inherited auf und wenn das sauber zurück kommt, kannst du die sav-Datei löschen.

Beim Create schaust du, ob die INI-Datei existiert (und vielleicht noch, ob sie nicht leer ist). Andernfalls suchst du nach einer sav-Datei und benennst die wieder in .ini um.

Ja, eine solche Lösung habe ich aktuell im Blick.
Ich hatte nur gehofft, dass es eine elegantere und performanetere Lösung gibt, als mit zwei Dateien zu arbeiten. Irgendwas Richtung Schattenkopien, NTFS-Möglichkeiten, wasauchimmer (wenn ich genau wüsste, was die beste Lösung ist, würde ich nicht fragen )

[nahpets]

Die einfachste Methode für zwei Dateien wäre doch, die INI-Datei vor UpdateFile mit

Delphi-Quellcode:

if FileExists(ChangeFileExt(FFileName,'.Save')) then DeleteFile(ChangeFileExt(FFileName,'.Save'));
RenameFile(ChangeFileExt(FFileName,'.Save'), NewName);

umzubenennen und dann

UpdateFile; auszuführen.

Beim Laden der INI-Datei wird geprüft, ob sie leer ist, wenn ja, wird geprüft, ob es die Umbenannte gibt, wenn ja, wird diese geladen.

Das ist performant und sollte im Bereich von ein paar wenigen Millisekunden ablaufen.

[Uwe Raabe]

Zitat von nahpets:

Die einfachste Methode für zwei Dateien wäre doch, die INI-Datei vor UpdateFile mit

Delphi-Quellcode:

if FileExists(ChangeFileExt(FFileName,'.Save')) then DeleteFile(ChangeFileExt(FFileName,'.Save'));
RenameFile(ChangeFileExt(FFileName,'.Save'), NewName);

umzubenennen und dann

UpdateFile; auszuführen.

Beim Laden der INI-Datei wird geprüft, ob sie leer ist, wenn ja, wird geprüft, ob es die Umbenannte gibt, wenn ja, wird diese geladen.

Und worin unterscheidet sich das jetzt von meinem Vorschlag

[nahpets]

Zitat von Uwe Raabe:

Zitat von nahpets:

Die einfachste Methode für zwei Dateien wäre doch, die INI-Datei vor UpdateFile mit

Delphi-Quellcode:

if FileExists(ChangeFileExt(FFileName,'.Save')) then DeleteFile(ChangeFileExt(FFileName,'.Save'));
RenameFile(ChangeFileExt(FFileName,'.Save'), NewName);

umzubenennen und dann

UpdateFile; auszuführen.

Beim Laden der INI-Datei wird geprüft, ob sie leer ist, wenn ja, wird geprüft, ob es die Umbenannte gibt, wenn ja, wird diese geladen.

Und worin unterscheidet sich das jetzt von meinem Vorschlag

Garnicht, hatte nur den Eindruck, dass Dein Vorschlag nicht so ganz vorstanden worden ist, und dahinter ein deutlich komplexerer Lösungsansatz vermutet wurde.

[Uwe Raabe]

Zitat von CodeX:

Ich hatte nur gehofft, dass es eine elegantere und performanetere Lösung gibt, als mit zwei Dateien zu arbeiten.

Performanteres als das wirst du kaum finden. Bei UpdateFile wird immer eine neue Datei erzeugt und damit eine eventuell bestehende gelöscht. Das Umbenennen der Datei verbraucht auch kaum Zeit, da es ausschließlich im Verzeichniseintrag stattfindet und die Datei selbst gar nicht angefasst wird.

Und das Schönste: es ist so stumpf einfach, daß man auch nach Jahren noch versteht, was da passiert.

[Der schöne Günther]

Ohne zu prüfen, einfach reingebrabbelt: Ich würde in diesem speziellen Fall bewusst nicht die RTL-Funktionen "RenameFile" oder was auch immer nehmen, sondern direkt die WinApi. Bei MoveFileEx scheint man atomares Verhalten bekommen zu können, sprich: Wenn der Strom genau beim "Umbenennen" der Datei flöten geht hast du garantiert entweder die alte oder die neue Datei, aber keinen Müll.

Siehe auch: https://social.msdn.microsoft.com/Fo...rum=windowssdk

[CodeX]

Spricht etwas dagegen, statt des Umbenennens der Datei bei UpdateFile direkt zu Beginn eine Kopie der aktuellen Datei zu erstellen (immer an der selben Stelle, sodass die Backup-Datei immer überschrieben wird) und anschließend per inherited den normalen Speicherprozess durchzuführen? Das würde jegliche Eventualität umgehen, dass beim Umbenennen etwas schief läuft und erscheint mir nicht Aufwändiger als der andere Weg.