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

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

[HolgerX]

Zitat von CodeX:

Zitat von Bjoerk:

Zitat von CodeX:

TMemIniFile beginnt bei ini.Free den Schreibvorgang (wo aller Inhalt auf ein Mal in die Datei geschrieben wird, also muss sie vermutlich auch erstmal geleert werden)..

Das ist nicht richtig. TMemIniFile schreibt lediglich bei UpdateFile.

Delphi-Quellcode:

destructor TIniFile.Destroy;
begin
  UpdateFile;         // flush changes to disk
  inherited Destroy;
end;

Hmm..

Was hat das UpdateFile bei Destroy vom TIniFile mit dem Destroy vom TMemIniFile zu tun?

Eigendlich doch nichts...

Also, wenn ein TMemIniFile genutzt wird, muss der Programmierer selber dafür sorgen, das per UpdateFile die Daten 'rechtzeitig' gespeichert werden.
Somit spätestens, wenn eine CanCLose Message von Windows kommt...

Bei Verwendung eines TIniFiles wird das Update bei Destroy selber aufgerufen. Somit kann es hier zu dem Problem kommen, das die Ini-Daten bei einem HardKill nicht gespeichert werden..

Welche Anpassungen am TMemIniFile hat de TE denn gemacht?

Wie bereits geschrieben sollten das UpdateData immer nach einer 'wichtigen' Änderung erfolgen.

Besser ist es, die Konfigurationsparameter in einem eigenen Objekt zu puffern und nur zum Laden / Speichern direct auf die IniFiles zuzugreifen.

(Meine Meinung )

[nahpets]

Ausgehend von den Delphi 7-Quellen zu TMemIniFile hat Holger recht:

Es wird nur gespeichert, wenn UpdateFile aufgerufen wird.

Im Destroy vom TMemFileIni (und auch in keiner anderen Routine) ist ein Speichern enthalten.

Daraus schließe ich jetzt mal ganz naiv:
Egal wie das Programm beendet wird, vor dem Beenden ist sicherzustellen, dass UpdateFile aufgerufen wird.

Ist dies sichergestellt und die Datei ist trotzdem leer oder gar nicht vorhanden, so liegt der Fehler ausserhalb des Programmes.

Dies könnte z. B. sein, wenn sie noch im Cache, aber noch nicht auf der Platte ist, der Rechner aber vorher schon aus ist, Rechner-/Windows-/Programmabsturz.

Nach Holgers Anregung stellt sich für mich jetzt die Frage: Wo wird bisher im Programm auf welchem Weg das Speichern durchgeführt.

Mit näherer Kenntnis dieses Vorganges könnten wir eventuell weiterführende Hilfestellung geben.

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

[notAssertor]

Und wie wäre es bei einem UpdateFile bei der CanClose-Abfrage?

Oh, ich sehe gerade die böse böse böse globale TMemIniFile, in der alles gespeichert wird...

Was ist denn mit dem ehrenwerten Sir Rufo los? Offline? Oder lässt er uns nur noch ein Weilchen spielen

@Sir Rufo: Grätsch' doch bitte ohne <Tgenericks> rein, damit es auch olle D7PE-Gruftis kapieren können Danke

@Alle: Ruft das Destroy des D7-TMemIniFile eigentlich immernoch das UpdateFile in neueren Delphis auf? Sollte man nicht dort zuerst mal nachschauen?

.

[Uwe Raabe]

Zitat von notAssertor:

@Alle: Ruft das Destroy des D7-TMemIniFile eigentlich immernoch das UpdateFile in neueren Delphis auf? Sollte man nicht dort zuerst mal nachschauen?

In D10 Seattle ruft TMemInifile.Destroy jedenfalls immer noch kein UpdateFile auf.

[himitsu]

NTFS reagiert bei Datenfehlern in der Verwaltung ganz nett ... es löscht einfach alles, was es nicht mag und schon ist eine Datei leer, wenn der PC abgestürzt ist.

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