Problem mit Fehlerauswertungen?

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:
[Blockierte Grafik: http://s4.postimage.org/u0rBJ.jpg]

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?

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...

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...

Zitat von RGH;765234

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;765234

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;765234

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?

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...

Zitat von RGH;765333

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 8O.

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

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.