hatte nur den Eindruck, dass Dein Vorschlag nicht so ganz vorstanden worden ist, und dahinter ein deutlich komplexerer Lösungsansatz vermutet wurde.
Den Eindruck habe ich mittlerweile aber auch...
Hm, sind meine Bedenken wirklich so daneben? Immerhin versuche ich hier ein Problem zu lösen, das eigentlich gar nicht auftreten dürfte, es aber wohl aufgrund ganz blöder Umstände doch tun kann. Der Vorschlag mit dem Umbenennen beinhaltet aber ja wiederum einen für mich intransparenten Zustand: Was passiert während des Umbenennens? Wenn dieser Befehl intern aus mehreren Teilschritten besteht und der Prozess genau dazwischen Abbricht, kann die Datei dann ja auch wieder verloren gehen. Ich sage nicht dass das so ist, aber zumindest sehe ich hier eine (für mich) Unbekannte.
Nein, Deine Bedenken sind selbstverständlich nicht daneben, aber die Sicherheit, die Du (vermutlich) anstrebst, wirst Du nicht erlangen.
Egal was Du in Deinem Programm machst:
Es ist immer möglich, dass zwischen zwei Programmschritten, die immer korrekt verlaufen, irgendwann doch mal der Strom weg ist, ein Hardwaredefekt auftritt, der Anwender einen Prozess abschießt...
Daher ja mein Vorschlag, immer wenn was wichtiges in der INI geändert wurde, UpdateFile aufzurufen.
Oder halt eine Routine implementieren, die Dir mehrere Sicherungeskopieen der Ini-Datei erstellen.
Dir scheint die Korrektheit und Speicherung der INI-Datei ja sehr wichtig zu sein. Beschreibe doch einfach mal kurz, warum, in welchem Umfeld...
Eventuell wird es für uns verständlicher, Deine Sorgen zu teilen und eventuell einen anderen Lösungsansatz zur Problemlösung zu finden.
Welche Datenmengen stehen in der INI-Datei?
Könnte eine Embedded-Firebird-Datenbank oder eine SQLite-Datenbank... oder sowas helfen?
Da sind die Daten in 'ner Transaktion per Commit weggeschrieben und der Stand ist dann beim nächsten Programmstart vorhanden, eine Datenbankdatei ist nicht bei 'nem misslungenen Update leer oder wird vor dem Schreiben gelöscht und dann neu erstellt.
Unter Delphi 7 sieht UpdateFile so aus:
Delphi-Quellcode:
procedure TMemIniFile.UpdateFile;
var
List: TStringList;
begin
List := TStringList.Create;
try
GetStrings(List);
List.SaveToFile(FFileName);
finally
List.Free;
end;
end;
In einer Ableitung könnte man das ja dahingehend überschreiben, dass man nach dem SaveToFile noch prüft, ob die Datei auch wirklich erstellt wurde und nicht leer ist.
Man könnte sie auch anschließend in eine zweite Stringliste laden und die beiden Stringlisten vergleichen...
Delphi-Quellcode:
procedure TMemIniFile.UpdateFile;
var
List: TStringList;
List2: TStringList;
begin
List := TStringList.Create;
List2 := TStringList.Create;
try
try
// Hier eventuell die in früherem Post vorgeschlagene "Historisierung" älterer INI-Dateien einbauen...
GetStrings(List);
List.SaveToFile(FFileName);
List2.LoadFromFile(FFileName);
if List.Text <> List2.Text
then begin
MessageDLG('
Abweichung zwischen vor und nach dem Speichern der INI-Datei.',mtError,[mbOk],0);
end;
except
on e :
Exception do begin
// Irgendwelche Sicherungsmaßnahmen...
MessageDLG(e.
Message,mtError,[mbOk],0);
end;
end;
finally
List2.Free;
List.Free;
end;
end;
(Das ist jetzt nur mal so "hingedaddelt" und nicht getestet.)
Schau Dir bitte in den Delphi-Quellen mal GetStrings von TMemIniFile an, könnte da (bedingt durch die verwendeten Daten) eventuell ein Fehler auftreten?