E/A Fehler 103 beim Assignfile

[TM6]

Ich habe hier ein Problem, welches ich nicht verstehe.
Ich versuche zu testen, ob ich eine Datei schreiben kann.

Code:

var
  lFile             : file      ;
begin
  if not FileExists( pDateiName ) then
    exit;

  FileMode := fmOpenReadWrite;

  assignfile( lFile , pDateiName );

...
end;

Dabei erhalte ich schon beim AssignFile den I/O Error 103.

Wenn ich das per try ... except abfange und assignfile noch einmal aufrufe, dann funktioniert es.

Das Problem taucht nur auf, wenn ich vorher in einer anderen unit (vollkommen andere Datei) einen nicht erfolgreichen Aufruf (Res <> 0 ) in der folgenden Art hatte (Datei pPath war schreibgeschützt)

Code:

  AssignFile(  lTestFile , pPath );
  if IOResult = 0 then begin
    rewrite( lTestFile , 1 );
    Res := IOResult;
    CloseFile( lTestFile );
  end;

Wo ist hier der Fehler?

[peterbelow]

Zitat von TM6:

Ich habe hier ein Problem, welches ich nicht verstehe.
Ich versuche zu testen, ob ich eine Datei schreiben kann.

Code:

var
  lFile             : file      ;
begin
  if not FileExists( pDateiName ) then
    exit;

  FileMode := fmOpenReadWrite;

  assignfile( lFile , pDateiName );

...
end;

Dabei erhalte ich schon beim AssignFile den I/O Error 103.

Wenn ich das per try ... except abfange und assignfile noch einmal aufrufe, dann funktioniert es.

Das Problem taucht nur auf, wenn ich vorher in einer anderen unit (vollkommen andere Datei) einen nicht erfolgreichen Aufruf (Res <> 0 ) in der folgenden Art hatte (Datei pPath war schreibgeschützt)

Code:

  AssignFile(  lTestFile , pPath );
  if IOResult = 0 then begin
    rewrite( lTestFile , 1 );
    Res := IOResult;
    CloseFile( lTestFile );
  end;

Wo ist hier der Fehler?

Setz IOResult auf 0 bevor Du irgendwelche Dateioperationen machst, das ist sicherer. Noch besser: vergiss diese uralten Dateifunktionen und verwende TFilestream et al., da ist die Fehlerbehandlung wesentlich konsistenter.

[Uwe Raabe]

Lass mal das CloseFile weg, wenn der IOResult einen Fehler meldet.

[TM6]

Zitat von Uwe Raabe:

Lass mal das CloseFile weg, wenn der IOResult einen Fehler meldet.

Das scheint zu funktionieren.
Ich wäre nicht auf die Idee gekommen, dass es daran liegen könnte.

In der Hilfe steht ja nur etwas von müssen und nicht dürfen:

Zitat:

Wenn ein E/A-Fehler auftritt, schließt Rewrite die Datei. Sie müssen CloseFile nicht aufrufen.

Danke!

Sollte man dann CloseFile allgemein nur situationsbedingt nutzen?
Ich habe noch zig Stellen im Code, an denen IOResult nicht ausgewertet wird.

[himitsu]

Kann es sein, dass vor dem AssignFile diese Datei-Variable einen "komischen" uninitialisierten Zustand besitzt?

Bist du dir sicher, dass der Fehler 103 wirklich aus dem AssignFile kam? (das kann eigentlich nicht sein)
[edit] Jupp, wie du schon sagtest, es gab vorher wo anders einen "letzten" Fehler,



IOResult ist immer der "letzte" Fehler, nicht der Status der letzten Ausführung.
Wenn etwas erfolgreich war, dann wird IOResult nicht auf 0 esetzt .... das müsstest du vorher selber machen.
Also genau das selbe Verhalten, wie beim GetLastError (auch wenn hier manche/zuviele Funktionen im Erfolgsfall es "bösartig" auf 0 setzen), und deswegen darf man es immer nur abfragen, wenn die Funktion vorher "Fehler" gesagt hat (niemals im Erfolgsfall).

AssignFile macht noch keine Dateizugriffe
und es liefert nur einen Fehler 3, wenn der übergebene Dateiname zu lang ist (MAX_PATH).



PS: Wie wäre es, wenn du dich von diesen "veralteten" Pascal-Funkionen verabschiedes und z.B. auf Streams umsteigst, oder auf anderes Objektorientiertes?

[Uwe Raabe]

Du hast zwar den Fehler nach Rewrite mit dem Abruf von IOResult gelöscht, aber das CloseFile produziert dann eben einen weiteren Fehler, den du dann aber auch mit IOResult zurücksetzen solltest. Oder das CloseFile nach einem fehlgeschlagenen Rewrite eben gar nicht erst aufrufen.

[TM6]

Zitat von himitsu:

[S]
PS: Wie wäre es, wenn du dich von diesen "veralteten" Pascal-Funkionen verabschiedes und z.B. auf Streams umsteigst, oder auf anderes Objektorientiertes?

Wenn man dazu Zeit hätte... Es sind halt nicht nur ein paar Tausend Zeilen Code.
Ein "die Zeit muss man sich nehmen" hilft da leider auch nicht weiter.
Priorität dafür wäre aktuell gegen 0.
Aber ich schreibe es mir auf die Agenda.

Noch einmal Danke für die Hilfe und Erklärungen.

Edit:
Ich habe jetzt doch nochmal an vielen Stellen den Code untersucht. Die eigentlichen Schreibroutinen laufen fast immer über tFileStream ab.
Es handelte sich fast nur um vorgelagerten alten Code, um den Schreibzugriff vorab zu überprüfen. Eigentlich nicht einmal notwendig.

[TM6]

Hat zwar nicht direkt mit dem Thema zu tun, ist aber eine Folge einiger Tests.

Wenn ich hier eine Exception auslöse

Code:

try
  FileStream := TFileStream.Create( Path, fmCreate );
except
  ..  
end;

dann erhalte ich eine "Benachrichtigung über Debugger-Exception" von Delphi.
Diese kann ich zwar pauschal über "Diesen Exception-Typ ignorieren" ausschalten. Aber nur pauschal.
Ist es eigentlich möglich, dies nur an bestimmten Stellen zu ignorieren?
Über $ irgendwas?

Möglicherweise war das der Grund der weiteren Nutzung von Assignfile, rewrite, ...

[himitsu]

Nein.

Es gibt Addons, wo man z.B. auch auf den Message-Text filtern kann, also nicht nur auf die Exception-Klasse.

ansonsten
https://www.delphipraxis.net/211220-...markieren.html
https://quality.embarcadero.com/browse/RSP-18827

zusätzlich
https://quality.embarcadero.com/browse/RSP-41311



Das als Grund dafür, neeeeeeeeeee?

CreateFile und das dann in ein THandleStream.

Via Ableitung oder per Class-Helper kann man es sich auch direkt in TFileStream oder THandleStream einfügen.