TFileStream - Datei bereits geöffnet ?

[Codewalker]

Zitat von littleDave:

Ich glaube sogar, dass das:
fmCreate or fmOpenWrite Probleme machen kann.

Probleme eigentlich nicht. Laut Delphi-Hilfe erstellt fmCreate eine Datei und wenn diese bereits vorhanden ist wird sie mit Schreibzugriff geöffnet.

[Muetze1]

@CodeWalker: Doch die Stelle ist soweit falsch, weil fmCreate eine vorhandene Datei überschreibt während fmOpenReadWrite die Datei nur öffnet aber ihren Inhalt bestehen lässt. Somit ist hier das Verhalten komplett gegensätzlich, deshalb können nicht beide angegeben werden. Aber das es zu keinen Problemen kommt wenn doch, liegt an der Implementierung von FileOpen() der VCL, welche nur auf fmCreate und nur in diesem Falle das richtige Flag an CreateFile() gibt -> es ignoriert das fmOpenReadWrite damit komplett, so lange fmCreate angegeben ist.

[slemke76]

Hallo,

ich wieder 8)

Also mit IsFileInUse hat es mehrere Tage gebraucht, aber es ist wieder "hängen" geblieben - ich könnte jetzt ein try...except...end drumherum bauen, aber ich würde schon gerne wissen, woher das Problem kommt.

Was ich jetzt noch probiert habe, ist mit Delphi 2007 statt Delphi 7 zu compilieren.

Hat aber auch nicht geklappt.

Jetzt werde ich die MappedStreams ausprobieren.

lg
Sebastian

[himitsu]

Zitat von slemke76:

Ich habe ausserdem gelesen, das TStream von Delphi gepuffert ist.

erstmal ist TStream abstract und da es aus diesem Grund erstmal garnichts ließt/schreibt, wird auch nichts gepuffert.

TFileStream(THandleStream) puffern selber nichts und die WindowsPufferung sollte bei diesem Problem keinen Einfluß haben, da sie vom Programm aus keinen Einfluß hat ... also wird FlushFileBuffers(Stream.Handle) nichts bewirken.


man müßte also erstmal rausbekommen welches Programm die Datei noch geöffnet hat (könntest ja z.B. mal mit einen Unlocker, oder 'nem Process Explorer selber nachsehn, wer das ist),

oder wenn es an deinem Programm liegt: warum/wo die Datei nicht mehr geschlossen/freigegeben wird.


PS: wenn die Datei noch geöffnet ist, dann bring es auch nichts, wenn du eine andere Komponente verwendest, um auf diese Datei zuzugreifen ... gesperrt ist gesperrt.
(abgesehn die Komponente ist defekt und der Fehler kommt von ihr ... aber TFileStream selber sollte diesen Fehler nicht verursachen)

[slemke76]

Hallo zusammen,

ich habe jetzt mal die Routine in ein einigenes Programm gekapselt; das Problem trat immer noch auf. Ich habe daraufhin mal ein wenig herumgespielt und es hat sich herausgestellt, dass die Kombination (oder nur der AV) Virenscanner und Betriebssystem das Problem verursacht haben:

Vista mit Kaspersky Antivirus 2009: keine Probleme
W2K3 SBS mit Kaspersky für Windows Servers 6.x: Nach kurzer Zeit Absturz, da die Datei in Benutzung sei.

Die Routine sieht so aus:

Delphi-Quellcode:

procedure TForm1.btnStartClick(Sender: TObject);
begin
  btnStart.Enabled:=false;
  btnStart.Caption:='running...';
  Timer1.Enabled:=true;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  Memo1.Lines.Add('rein');
  Timer1.Enabled:=false;
  DoSave();
  Timer1.Enabled:=true;
  Memo1.Lines.Add('raus');
end;

Delphi-Quellcode:

procedure DoSave();
var Stream: TFileStream;
    XMLFile: String;
    DomToXmlParser1: TDomToXmlParser;
    DomImplementation1: TDomImplementation;
    FDoc: TDOMDocument;
    FNodeElement: TDomElement;

begin
  XMLFile:='test.xml';
  // ----- XML-Zeugs -----
  DomImplementation1:=TDomImplementation.Create(nil);
  FDoc := TDomDocument.Create(DomImplementation1);
  DomToXmlParser1:=TDomToXmlParser.Create(nil);
  DomToXmlParser1.DOMImpl:=DomImplementation1;

  // --- XML root für Schnittstelle anlegen ---
  FNodeElement:=TDomElement.Create(FDoc, 'TEST');
  FDoc.AppendChild(FNodeElement);

  Stream := TFileStream.Create(XMLFile, fmCreate);
  DomToXmlParser1.WriteToStream(FDoc, 'UTF-8', Stream);
  Stream.Free;

  FNodeElement.Free;
  DomToXmlParser1.Free;
  FDoc.Free;
  DomImplementation1.Free;
end;

lg
Sebastian

[himitsu]

also könnte es so aussehn, als wenn der Virenscanner die Datei noch geöffnet hat.

abgesehn, daß zur Sicherheit in DoSave in paar Try-Except/Finally nicht schaden könnten, damit bei einem/dem Fehler nicht vergessen wird etwas freizugeben ... vorallem die Datei zu schließen.

PS: wenn der Code mehrmals die Minute aufgerufen wird, warum öffnest du diese Datei dann ständig neu?
könnte sie denn nicht einmal geöffnet und die ganze Zeit über offen gelassen werden?

Da IsFileInUse scheinbar nichts bringt, da zwischen diesem und TFileStream.Create die Datei immernoch gesperrt werden kann (bzw. was anscheind auch schon passiert ist):

Delphi-Quellcode:

procedure DoSave();
var Stream: TFileStream;
    XMLFile: String;
    DomToXmlParser1: TDomToXmlParser;
    DomImplementation1: TDomImplementation;
    FDoc: TDOMDocument;
    FNodeElement: TDomElement;
    B: Boolean;

begin
  XMLFile:='test.xml';
  // ----- XML-Zeugs -----
  DomImplementation1:=TDomImplementation.Create(nil);
  FDoc := TDomDocument.Create(DomImplementation1);
  DomToXmlParser1:=TDomToXmlParser.Create(nil);
  DomToXmlParser1.DOMImpl:=DomImplementation1;

  // --- XML root für Schnittstelle anlegen ---
  FNodeElement:=TDomElement.Create(FDoc, 'TEST');
  FDoc.AppendChild(FNodeElement);


  B := False;
  repeat  
    try
      Stream := TFileStream.Create(XMLFile, fmCreate);
      B := True;
    except
      Sleep(0);
    end;
  until B;
  try
    DomToXmlParser1.WriteToStream(FDoc, 'UTF-8', Stream);
  finally
    Stream.Free;
  end;

  FNodeElement.Free;
  DomToXmlParser1.Free;
  FDoc.Free;
  DomImplementation1.Free;
end;

OK, es ist nicht wirklich optimal und vorallem ein Except ohne Fehlerbehandlung wird nicht grad gern gesehn, aber was soll's
(zusetzlich noch ein (paar) Try-Finally für das ganze XML-Zeugs könnten dennoch nicht Schaden)

[slemke76]

Hi !

Der Code ist wirklich gut; ich habe es jetzt im Moment anders gelöst, aber das wird nochmal angepasst. Danke für den Input.
try-except für XML ist nicht wirklich notwendig - die Routinen laufen absolut problemlos; praktisch gesehen gibt es da nix, was abstürzt

lg
Sebastian

[himitsu]

Zitat von slemke76:

try-except für XML ist nicht wirklich notwendig - die Routinen laufen absolut problemlos; praktisch gesehen gibt es da nix, was abstürzt

Na dann ist ja gut ... bin' halt nur gewohnt, daß zuviele DelphiObjekte mit Exceptions nur so um sich werfen

Aber wenn das so ist, dann sollte es ja reichen, wenn in der Schleife das Try-Except und "B" wegkommt und stattdessen einfach der Wert von "Stream" geprüft wird. (war mir aber fast sicher, daß der Konstruktor im Fehlerfall eine exception wirft )

grad nachgesehn ... wenn die datei nicht geöffnet wird, dann wird mit EFCreateError geworfen.