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

[nahpets]

Zitat von CodeX:

Gibt es eine Möglichkeit, solche Probleme grundsätzlich zu verhindern?

Immer dann, wenn was "wichtiges" in die INI reingekommen ist UpdateFile aufrufen und nicht nur drauf hoffen, dass es im Destroy automatisch aufgerufen wird.

[CodeX]

Zitat von nahpets:

Immer dann, wenn was "wichtiges" in die INI reingekommen ist UpdateFile aufrufen und nicht nur drauf hoffen, dass es im Destroy automatisch aufgerufen wird.

Ich sehe den Zusammenhang zu dem Problem hier nicht. Ich hoffe nicht darauf, dass irgendetwas beim Destroy aufgerufen wird, sondern habe festgestellt, dass es offensichtlich in seltenen Fällen dazu kommen kann, dass der gesamte Ini-Inhalt verloren gehen kann, wenn das Freigeben der Ini unterbrochen wird.

[notAssertor]

Aus der HLP-Datei von Delphi 7 Personal kopiert:

----------------
Das INI-Dateiformat wird noch häufig eingesetzt, besonders in Konfigurationsdateien (z.B. auch in DSK-Dateien). Das Format ist insbesondere für plattformübergreifende Anwendungen nützlich, da die Benutzung einer Systemregistrierung für Konfigurationsdaten nicht immer möglich ist. BaseCLX macht mit den beiden Klassen TIniFile und TMemIniFile das Lesen und Schreiben von INI-Dateien sehr einfach.

TIniFile arbeitet direkt mit der INI-Datei auf der Festplatte, während TMemIniFile alle Änderungen im Speicher puffert und erst nach Aufruf der Methode UpdateFile in die Datei schreibt.

Bei der Instantiierung eines TIniFile- oder TMemIniFile-Objekts übergeben Sie den Namen der INI-Datei als Parameter an den Konstruktor. Ist die Datei nicht vorhanden, wird sie automatisch erstellt. Anschließend können Sie Werte mit einer der Lesemethoden (ReadString, ReadDate, ReadInteger oder ReadBool) abrufen. Das Lesen eines ganzen Abschnitts ist mit der Methode ReadSection möglich. Geschrieben wird mit den Methoden WriteBool, WriteInteger, WriteDate oder WriteString.
----------------

Die fette rote Hervorhebung stammt von mir.

Mir scheint ein beherztes UpdateFile möglich zu sein

Was spricht denn in neueren Delphis dagegen, das UpdateFile einfach mal reinzuklatschen?

Frag' ich ja nur ganz naiv mit D7PE .

[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 )

[mm1256]

Zitat von CodeX:

...offensichtlich in seltenen Fällen dazu kommen kann, dass der gesamte Ini-Inhalt verloren gehen kann, wenn das Freigeben der Ini unterbrochen wird.

Wann bzw. wie wird denn die INI beim Programmende freigegeben? Das scheint mir der erfolgversprechende Ansatzpunkt zu sein.

[nahpets]

Zitat von CodeX:

Zitat von nahpets:

Immer dann, wenn was "wichtiges" in die INI reingekommen ist UpdateFile aufrufen und nicht nur drauf hoffen, dass es im Destroy automatisch aufgerufen wird.

Ich sehe den Zusammenhang zu dem Problem hier nicht. Ich hoffe nicht darauf, dass irgendetwas beim Destroy aufgerufen wird, sondern habe festgestellt, dass es offensichtlich in seltenen Fällen dazu kommen kann, dass der gesamte Ini-Inhalt verloren gehen kann, wenn das Freigeben der Ini unterbrochen wird.

Richtig und deshalb mein Vorschlag, zwischendurch UpdateFile aufzurufen, sonst wird es nur im Destroy aufgerufen und es ist nicht absolut zwingend sichergestellt, dass Destroy aufgerufen wird (z. B. Windows "killt" das Programm beim Runterfahren, der Anwender beendet es per Taskmanager, aus welch anderem Grund auch immer wird es unsauber beendet, stürzt ab, Windows macht die Grätsche...)
Denn offensichtlich wir ja Destroy in seltenen Fällen nicht aufgerufen und daher geht in ebendiesen seltenen Fällen der Inhalt verloren.

@notAssertor - nichts anderes wollte ich mit meinem Post sagen.

Der Aufruf von UpdateFile ist nicht verboten, auch wenn UpdateFile automatisch im Destroy aufgerufen wird.

[mm1256]

Hallo,

aber wenn die Vermutung des TE richtig ist, dass das Problem "während" des Destroy auftritt (Windows schießt die App während des Schreibvorganges beim "OnClose" ab), und das ist aus meiner Sicht auch ziemlich naheliegend, dann hilft ein UpdateFile während des Betriebs auch nicht wirklich. Hier würde nur eine Sicherungskopie helfen.