Problem mit Fehlerauswertungen?

[AHT]

Ich glaube, das hier ist evtl. das gleiche Problem...
Wenn ich ab Vista eine EXE im Ordner Program Files (Rechte und Umleitung des Ordners beachten) öffne (kein Manifest), erzeugt folgender Quelltext

Declare File$, F#
File$ = LoadFile$("Datei laden", "*.*")
'Set("FileMode",0)
IF File$ <> ""
 Assign #2, File$
 OpenRw #2
 DIM f#, FileSize(File$)
 Assign #1, File$
 OpenRw #1
 Print FileSize(File$)
 BlockRead(File$, f#, 0, FileSize(File$))
 $B "Test"
 Print Char$(f#, 0, SizeOf(f#))
 $B "Test 2"
 CloseRw #1
 CloseRw #2
 dispose f#
endif

bei mir folgenden Fehler:


Wie kommt das?
OpenRW schlägt hier fehl, da zum Öffnen (Read / Write) einer EXE im Ordner Program Files Adminrechte erforderlich sind - die hat das Programm aber nicht.
Normalerweise würde hier in VirtualStore umgeleitet werden - bei bestimmten Dateiendungen findet aber eine solche Umleitung nicht statt (unter anderem EXE und DLL Dateien). Profan merkt sich hier, das OpenRW fehlgeschlagen ist (Errorcode 5 = Zugriff verweigert). BlockRead würde hier problemlos funktionieren, aufgrund des vorangegangenen Fehlers schlägt der Befehl hier aber fehl. Muss das sein?

[AHT]

@Roland:
Das Problem ist schon sehr alt. Blätter mal einige Jahre in deinem Forum zurück, da hast du damals dazu angeraten, vor jeder Dateiaktion %IORESULT auszulesen und damit auf 0 zu setzen.
Ich persönlich denke, dass man Fehler dort auswerten sollte, wo sie passieren und nicht einen Fehlercode mitschleppen und dann auf die Sachen anwenden sollte, bei denen gar kein Fehler passiert...

[RGH]

@AHT: Hier handelt sich um das ganz normale Verhalten von Pascal-Dateioperationen. Wenn man sich an meinen Rat hält, kann man damit gut umgehen. Gerade nach einem Öffnen einer Datei sollte man immer überprüfen, ob es geklappt hat.

Aber in diesem speziellen Fall spricht natürlich nichts dagegen, dass ich in der BlockRead-Funktion %IOResult sicherheitshalber selbst zurücksetze. In XProfan 12 wird es so sein.

Gruß
Roland

[AHT]

Das ganze ist eine böse Falle. Im Prinzip müsste man dann ja wirklich vor jeder Dateioperation

• Print #
• Input #
• Rewrite
• OpenRw
• Open
• Close
• CloseRw
• BlockRead
• BlockWrite
• GetFileSize
• GetFAttr
• GetFDate$
• GetFTime$
• Append
• Seek
• ...?

zumindestens folgendes verwenden:

io%=%IOResult

Ab Vista läuft bei Dateien sehr viel schief, da selbst ein Admin normalerweise keine Adminrechte hat - ob etwas schief läuft und wann, das ist unter anderem von der Datei selbst und den Systemgegebenheiten abhängig (auch davon, wie das Programm gestartet wurde) - wie man in meinem Beispiel sieht, sogar von der Dateiendung.
Ein Programm läuft unter Umständen (setzt man nicht zurück) dann auf dem einen Rechner, auf dem nächsten läuft es aber wiederum nicht. Da nicht genau fest steht, welche Profanbefehle überhaupt intern auf %IORESULT reagieren, weiß man auch nicht genau, was man überhaupt zurücksetzen muss und was nicht...

[RGH]

Zitat von AHT

Das ganze ist eine böse Falle. Im Prinzip müsste man dann ja wirklich vor jeder Dateioperation ...

Nein, nicht vor, sondern nach jeder Dateioperation sollte man überprüfen, ob sie funktioniert hat, in dem man %IOResult abfragt. Also auf alle Fälle nach OpenRW, Reset, Append, Rewrite und natürlich nach allen Schreib- und Leseoperationen, bei denen eine Dateinummer einer geöffneten Datei anzugeben ist.
Die genannten Rechteprobleme zeigen sich in der Regel ja bereits beim Öffnen der Datei. Wenn das schon nicht klappt, sind weitere Schreib- oder Leseoperationen hinfällig.
Auch nach dem Schließen der Datei mit Close sollte mit %IOResult überprüft werden, ob es funkionierte.

Tatsächlich wird bei den allermeisten Dateioperationen allerdings %IOResult bereits von mir vor Ausführung der Funktion zurückgesetzt. Bei BlockWrite und BlockRead war das bisher nicht der Fall, wird aber in XProfan 12 auch so sein.

Gruß
Roland


Gruß
Roland

[AHT]

Zitat von RGH

Nein, nicht vor, sondern nach jeder Dateioperation sollte man überprüfen, ob sie funktioniert hat, in dem man %IOResult abfragt. Also auf alle Fälle nach OpenRW, Reset, Append, Rewrite und natürlich nach allen Schreib- und Leseoperationen, bei denen eine Dateinummer einer geöffneten Datei anzugeben ist.

Nach welchen Befehlen genau? Zum Beispiel auch bei GetFileSize? Siehe auch hier! Was setzt denn jetzt %IORESULT überhaupt alles?

Zitat von RGH

Die genannten Rechteprobleme zeigen sich in der Regel ja bereits beim Öffnen der Datei. Wenn das schon nicht klappt, sind weitere Schreib- oder Leseoperationen hinfällig.

Das Problem dabei ist aber, dass die darauffolgenden Aktion nichts mit dem vorher geschehenen Fehler zu tun haben muss und trotzdem fehlschlägt, obwohl sie eigentlich funktionieren würde.

Zitat von RGH

Tatsächlich wird bei den allermeisten Dateioperationen allerdings %IOResult bereits von mir vor Ausführung der Funktion zurückgesetzt.

Bei welchen genau und bei welchen Befehlen wird das nicht getan? Was reagiert überhaupt genau auf %IORESULT?

[RGH]

Zitat von AHT

Nach welchen Befehlen genau? Zum Beispiel auch bei GetFileSize? Siehe auch hier! Was setzt denn jetzt %IORESULT überhaupt alles?

Wie ich schon schrieb: alle Dateioperationen, die eine Dateinummer als Parameter erwarten.

Das Problem dabei ist aber, dass die darauffolgenden Aktion nichts mit dem vorher geschehenen Fehler zu tun haben muss und trotzdem fehlschlägt, obwohl sie eigentlich funktionieren würde.

Das ist natürlich konstruierbar: Du öffnest Datei A. Dann öffnest Du Datei B, ohne dich darum zu kümmern, ob es funktioniert hat. Es schlägt fehl und Du merkst es nicht. Nun machst Du wieder etwas mit Datei A und der Fehler schlägt zu, weil Du versäumt hast, ihn zuvor abzufangen.

Gruß
Roland

[Bangkok]

Bitte die RTF nicht vergessen, da scheint das gleiche Problem zu sein

[AHT]

@Roland:
GetFilesize schlägt aber nicht fehl, wenn %IORESULT von einer anderen Aktion gesetzt wurde.

Problem bei der ganzen Sache
%IORESULT dürfte von GetLastError gesetzt werden. Die Adresse des von GetLastError ausgelesenen Errorcodes (LastErrorValue) ist aber ein Member des TEB (das weiß jedes Kleinkind), und der TEB kann problemlos von jeder anderen Anwendung ermittelt und der Inhalt von LastError geändert werden.
Reagieren irgendwelche Profanbefehle also blind auf %IORESULT, kann man das Funktionieren einer Anwendung problemlos von außen steuern - das dazu nötige Programmierwissen geht gegen null.
Bitte mal sehr genau überdenken, was da evtl. noch zu ändern ist...

[RGH]

Zitat von AHT

@Roland:
GetFilesize schlägt aber nicht fehl, wenn %IORESULT von einer anderen Aktion gesetzt wurde.

Ja, das ist die berühmte Ausnahme von der Regel. Da die zugrundeliegende Delphi-Funktion IOResult nicht setzt, frage ich es auch nicht ab.

%IORESULT dürfte von GetLastError gesetzt werden.

Hier liegst Du falsch! %IOResult entspricht exakt der Delphi-Systemvariablen IOResult, die ausschließlich von Delphi-Dateioperationen gesetzt wird, und das mit den in der Hilfe zu %IOResult genannten Werten. Und IOResult gab es schon lange, bevor sich bei Microsoft irgend jemand das GetLastError ausgedacht hatte.

Gruß
Roland

[AHT]

Zitat von RGH

Hier liegst Du falsch!

Hab's gerade getestet, damit liegst du leider falsch

Wie von mir bereits angedeutet lassen sich Profanbefehle durch das Setzen des Fehlercodes ins Nirwana schicken (von einem Fremdprogramm aus). Getestet habe ich das mit BlockRead .

Edit: Kommando zurück, hatte noch einen Copy / Paste Fehler drin . Extern scheint da zum Glück nichts möglich zu sein.

[AHT]

Kleiner Zusatz: Was natürlich möglich ist, ist sich einen Pointer auf die interne IORESULT Variable zu verschaffen und diese von einem fremden Prozess aus direkt zu ändern (gestern getestet). In der Praxis wäre ein Hooking da aber besser und leichter auszuführen. Mir ging es da erst mal um einen Zusammenhang mit dem LastErrorValue, und der besteht zum Glück nicht.