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

[CodeX]

Ich nutze in meiner Software eine abgeleitete Version von TMemIniFile zum Arbeiten mit Ini-Dateien. Das funktioniert eigentlich auch absolut problemlos. Allerdings gibt es wohl irgendeine Konstellation, die dazu führt, dass der Inhalt der Ini-Datei verloren geht.
Ein Anwender berichtet, dass das bei ihm alle paar Wochen nach dem Neustarten der Fall ist (Software läuft minimiert beim Herunterfahren und startet sich nach der Windowsanmeldung automatisch). Ein zweiter Anwender berichtete, dass dies bei ihm ein Mal passiert ist, als der Rechner während der Verwendung der Software abgestützt ist (hatte nichts mit der Software zu tun und der Ini-Verlust ist nach langer Verwendung erst ein Mal aufgetreten. Da die Datei nach dem Programmstart automatisch erstellt wird, kann ich nicht sagen, ob die ganze Datei weg ist oder "nur" komplett geleert.

Nun bin ich leider etwas ratlos, wie es dazu kommen kann. Da dies so extrem selten auftritt, könnte es sich um ein ganz blödes Timing handeln: 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), Rechner geht plötzlich aus, ini-Datei leer. Wäre so etwas denkbar oder sollte das TMemIniFile eigentlich verhindern? Gibt es eine Möglichkeit, solche Probleme grundsätzlich zu verhindern? Oder hat jemand andere Ideen, womit es zusammenhängen könnte?

[Der schöne Günther]

Das hatte ich mit TMemIniFile auch einmal. Wenn du dir die Implementierung anschaust dann basiert das auf einer TStringList die erst einmal die gesamte Datei "leert" und dann noch einmal von vorne alles reinschreibt. Wenn dazwischen drin der Saft ausgeht dann hast du eine leere Datei.

Das Abmelden/Herunterfahren/Neustarten finde ich, im Standardfall, bei der VCL eine Katastrophe. Im Regelfall schießt Windows deine Anwendung knallhart ab sobald das Hauptformular zerstört wurde. Ich weiß nicht wie das mit den Dateipuffern ist- Vielleicht übernimmt er nur noch das "leermachen" der Datei, nicht mehr was dort hinein sollte?

[himitsu]

TMemIniFile schreibt nur in den WindowsFileCache, aber wann das auf der Platte landet, das entscheidet Windows.

Man kann natürlich die TMemIniFile auch so erweitern, daß sie (a) den Cache löscht und (b) notfalls auch noch ein Backup des alten Dateiinhaltes hält, so lange noch geschrieben wird.


Wie groß sind deine INI?

[CodeX]

Zitat von himitsu:

Wie groß sind deine INI?

Unterschiedlich, je nach Verwendung. Sagen wir 10KB - 200KB. Spielt das eine große Rolle?

Zitat von himitsu:

Man kann natürlich die TMemIniFile auch so erweitern, daß sie (a) den Cache löscht und (b) notfalls auch noch ein Backup des alten Dateiinhaltes hält, so lange noch geschrieben wird.

Ist das ein theoretischer Ansatz oder hast Du das schon irgendwo verwendet/gesehen? Wenn Du da Link oder Codeschnippsel für mich hättest, wäre das toll!

[Sir Rufo]

Grundsätzlich lösen kann man das, wenn man keine Ini-Datei verwendet.

Will man die Ini-Datei meiden aber mit TIniFile trotzdem arbeiten, dann schreibt man sich einen Ableitung und legt z.B. eine SQlite DB darunter.

Das ist weniger Arbeit als man vermuten mag.

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

procedure TMemIniFile.UpdateFile;
var
  List: TStringList;
begin
  List := TStringList.Create;
  try
    GetStrings(List);
    List.SaveToFile(FFileName);
  finally
    List.Free;
  end;
end;

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

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