ini file manchmal zerstört

[surfer007]

Hallo,

ich benutze eine ini Datei um Einstellungen zu speichern (TMemIni). Das ganze klappt auch soweit. Hier ein Beispiel, ich arbeite mit try/except und try/finally da TMemIni. Da ich schon den Fehler hatte "kann nicht erzeugt werden da von einem anderen Prozess benutzt" noch die FileInUse Abfrage.

Delphi-Quellcode:

procedure TForm1.CheckBoxSwichResolutionClick(Sender: TObject);
var
  s : String;
  myIni : TMemIniFile;
begin
  if bStartMerker then Exit;
  if CheckBoxSwichResolution.Checked then s := 'TRUE' else s := 'FALSE';
  WaitIfIniFileLocked;
  try
    myIni := TMemIniFile.Create(sPath + 'my.ini');
    try
      myIni.WriteString('DATA', 'SWITCHRESOLUTION', s);
      myIni.UpdateFile;
    finally
      MyIni.Free;
    end;
  except
    MyLogAdd('ERROR' + ',' + 'E=22', False);
  end;
end;

function FileInUse(FileName: string): Boolean;
var hFileRes: HFILE;
begin
  Result := false;
  hFileRes := 0;
  if NOT FileExists(FileName) then Exit;
  try
    hFileRes := CreateFile(PChar(FileName),
                                    GENERIC_READ or GENERIC_WRITE or GENERIC_EXECUTE,
                                    0,
                                    nil,
                                    OPEN_EXISTING,
                                    FILE_ATTRIBUTE_NORMAL,
                                    0);
    Result := (hFileRes = INVALID_HANDLE_VALUE);
  finally
    if NOT Result then CloseHandle(hFileRes);
  end;
end;

procedure TForm1.WaitIfIniFileLocked;
var
  i : Integer;
begin
  for i := 1 to 50 do begin
    Application.ProcessMessages;
    try
      if FileInUse(sPath + 'my.ini') then begin
        MyDelay(100);
      end else begin
        Exit;
      end;
    except
      MyLogAdd('Error WaitIfIniFileLocked', False);
    end;
  end;
end;

Nun habe ich einen Kunden bei dem ca. alle 2 Wochen die INI Datei zerschossen ist. D.h. die INI ist normalerweise ca. 30 KB gross, und im Fehlerfall dann nur noch 100 Byte und der Rest an Daten fehlt einfach. Da bei Programmstart die Einstellungen aus der INI geladen werden, gibt es dann natürlich Probleme, da Variablen nicht vorhanden sind. Normalerweise passiert sowas ja nur, wenn z.B. während des Schreibvorganges der Strom ausfällt, dann ist klar das der Rest weg ist.

Irgendwelche Tips zu dem Thema kaputte INI? Warum passiert das "manchmal" (mein Lieblings Wort wenn es um bugs geht).

[Luckie]

Wie kann denn die Ini Datei von einem anderen Prozess noch benutzt werden? Oder haben zwei Programme darauf zugriff? Wenn es nur ein ist, dann kann das nur passieren, wenn nach der Benutzung das handle nicht geschlossen wird. Und hier wäre das ein Freigeben des Ini-Objektes. Kann also der Fall eintreten, dass das Objekt nicht ordnungsgemäß wieder frei gegeben wird?

[Popov]

Nun, ich selbst arbeite, wenn es die Ini ist, eher mit der TIniFile, so dass ich die Eigenarten der TMemIni nicht kenne. Ist TMemIni die TMemIniFile? Ok, die TIniFile leitet sich inzwischen von der TMemIniFile ab, hat sie aber früher nicht gemacht. Obwohl, bei 30 KB ist TMemIni wohl die bessere Wahl.

Woraus ich hinaus will. Kann es sein, dass dem Kunden alle 2 Wochen der Rechner abschmiert, noch bevor die Ini korrekt upgedatet wurde?

[Bjoerk]

TMemIniFie ist soweit schon in Ordnung. Vermute mal, daß eher mehrere Prozesse gleichzeitig auf die selbe ini zugreifen wollen? Sonst vielleicht einfach irgendwo free oder UpdateFile vergessen?

[Popov]

Wie ich schon sagte, ich hab mich bisher wenig mit der TMemIni beschäftigt, aber

Delphi-Quellcode:

    try
      myIni.WriteString('DATA', 'SWITCHRESOLUTION', s);
      myIni.UpdateFile;
    finally
      MyIni.Free;
    end;

Wenn es hier einen Fehler gibt, dann sollte eigentlich keine Fehlermeldung kommen, d. h. man kriegt es gar nicht mit.

Gehen wir man davon aus, dass der Fehler hier in dem Beispiel bei WriteString passiert, wird doch UpdateFile nicht ausgeführt. Somit stellt sich die Frage ob UpdateFile nicht besser im Finally Block aufgehoben wäre?

Obwohl das nicht der Fehler sein kann, da in dem Fall nur die Liste nicht aktualisiert würde.

[Bjoerk]

Würd‘ ich nich' machen, UpdateFile produziert ja hier die Exception. TMemInfIle arbeitet intern mit einer StringList. WriteString fügt den Wert nur in diese Stringliste ein. Erst bei UpdateFile erfolgt ein List.SaveToFile. TMemIniFile.WriteString kann im Gegensatz zu IniFiles keinen IO-Fehler produzieren.

Vielleicht so? (ungetestet):

Delphi-Quellcode:

function CanUseIniFile(const Filename: string): boolean;
  procedure Wait200;
  var
    ATime: Cardinal;
  begin
    ATime := GetTickCount;
    repeat
    until GetTickCount - ATime > 200;
    Application.ProcessMessages;
  end;
var
  N, IO: integer;
  F: TextFile;
begin
  Result := true;
  if (FileName <> '') and FileExists(FileName) then
  begin
    AssignFile(F, FileName);
    N := 0;
    repeat
      {$I-} Reset(F); {$I+}
      IO := IOResult;
      if IO <> 0 then
      begin
        Wait200;
        Inc(N);
      end;
    until (IO = 0) or (N = 20);
    Result := (IO = 0);
    if not Result then
      MessageDlg(SysErrorMessage(IO), mtWarning, [mbOK], 0)
    else
      CloseFile(F);
  end;
end;

Edit: Muß 2 mal geprüft werden

Delphi-Quellcode:

    if CanUseIniFile(sPath + 'my.ini') then
    begin
      myIni := TMemIniFile.Create(sPath + 'my.ini');
      try
        myIni.WriteString('DATA', 'SWITCHRESOLUTION', s);
        if CanUseIniFile(sPath + 'my.ini') then
          myIni.UpdateFile;
      finally
        MyIni.Free;
      end;
    end;

[Sir Rufo]

Zitat von Popov:

Wie ich schon sagte, ich hab mich bisher wenig mit der TMemIni beschäftigt, aber

Delphi-Quellcode:

    try
      myIni.WriteString('DATA', 'SWITCHRESOLUTION', s);
      myIni.UpdateFile;
    finally
      MyIni.Free;
    end;

Wenn es hier einen Fehler gibt, dann sollte eigentlich keine Fehlermeldung kommen, d. h. man kriegt es gar nicht mit.

Gehen wir man davon aus, dass der Fehler hier in dem Beispiel bei WriteString passiert, wird doch UpdateFile nicht ausgeführt. Somit stellt sich die Frage ob UpdateFile nicht besser im Finally Block aufgehoben wäre?

Obwohl das nicht der Fehler sein kann, da in dem Fall nur die Liste nicht aktualisiert würde.

Wenn innerhalb von try..finally eine Exception ausgelöst wird, dann wird der finally Teil noch abgearbeitet aber die Exception rauscht weiter, bis diese gefangen oder aber aufpoppt.

[Uwe Raabe]

Wenn die Ini-Datei nur für das eine Programm zuständig ist, sollte eigentlich kein Zugriff eines anderen Prozesses darauf möglich sein. Die Tatsache, daß die Datei manchmal von einem anderen Prozess geöffnet ist, wäre für mich schon mal der erste Ansatzpunkt.

TMemIniFile list die Datei beim Create und schreibt Sie beim UpdateFile. Zwischendrin kann alles mögliche passieren. Auch die vorherige Abfrage, ob die Datei in Benutzung ist, verhindert keine konkurrierenden Zugriffe, da kein Locking verwendet wird.

Mit den ganzen Überprüfungen bekämpfst du nur die Symptome aber nicht die Ursache.

[Bjoerk]

Daß in der Millisekunde von Create bis UpdaeFile die Datei sonst wo benutzt wird? Klar, kann passieren, aber eher unwahrscheinlich. Wenn auf die Datei aber wirklich so wild unstrukturiert zugegriffen wird, dann würd' ich aus der IniFile eine TextFile machen. Dann weiß man wenigstens, daß von Reset/Rewrite/Append bis CloseFile kein anderer Prozess auf die Datei zugreifen kann. Ggf. ein kleiner IniFileParser schreiben der so arbeitet.

[Bjoerk]

Hab' eben auch mal mein function getestet. Ist Nonsens. Reset kann auch auf bereits geöffnete Dateien angewendet werden.