Pfad nicht gefunden ...

[Ulrich F. Heidenreich]

Hallo!

Wenn's jetzt kein Turbo-Pascal-Fehler ist, bin ich hier wohl richtig.
Gegeben sei das unterm Win95 liegende DOS, ein TP3-Compilat Namens
datimlog.exe im Verzeichnis D:\tools. Und D:\tools im "Set Path=".
(Prompt ist &p&g). Damit geschieht nun folgendes Seltsames:

D:\Spamsinker>datimlog
Runtime error 003 at 0009:03E8.

D:\Spamsinker>d:\tools\datimlog
Runtime error 003 at 0009:03E8.

D:\Spamsinker>cd \tools

D:\Tools>datimlog
30.07.2011 10:11:08

Was zum Henker geht da ab? "Runtime Error 003" steht für "Path not
found". Das ganze Programm nutzt gar keinen Pfad, sondern schreibt
einfach nur Datum und Uhrzeit auf den Schirm.

TIA,
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Wenn's jetzt kein Turbo-Pascal-Fehler ist, bin ich hier wohl richtig.
Gegeben sei das unterm Win95 liegende DOS, ein TP3-Compilat Namens
datimlog.exe im Verzeichnis D:\tools. Und D:\tools im "Set Path=".
D:\Spamsinker>datimlog
Runtime error 003 at 0009:03E8.
D:\Spamsinker>d:\tools\datimlog
Runtime error 003 at 0009:03E8.
D:\Spamsinker>cd \tools
D:\Tools>datimlog
30.07.2011 10:11:08
Was zum Henker geht da ab? "Runtime Error 003" steht für "Path not
found".

Vermutung: Das Programm hat Probleme, wenn es aus einem Pfad mit langem
Namen aufgerufen wird. Du könntest testweise den Rechner im reinen DOS
starten und dann nochmal von diesem Pfad aus testen.

Post by Ulrich F. Heidenreich
Das ganze Programm nutzt gar keinen Pfad, sondern schreibt
einfach nur Datum und Uhrzeit auf den Schirm.

Falls Du das Programm selber geschrieben hast: Nirgends ein
GetCurrentDir, DirectoryExist (oder wie die Funtionen damals hießen <g>)
oder ParamStr(0)? Zeigt ein simples, mit TP3 geschriebenes "Hello World"
die selben Probleme?

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost
Vermutung: Das Programm hat Probleme, wenn es aus einem Pfad mit langem
Namen aufgerufen wird.

Treffer. Versenkt. Nur warum wohl? Und warum neuerdings erst jetzt?
Das lief mehr als nur monatelang im Verzeichnis "Spamsinker" und machte
erst seit einigen Tagen diesen Unfug. Ich nutze es einklich überall, wo
es darum geht, per "datimlog>>logfile" einen Zeitstempel in $logfile zu
hinterlassen.

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Das ganze Programm nutzt gar keinen Pfad, sondern schreibt
einfach nur Datum und Uhrzeit auf den Schirm.

Falls Du das Programm selber geschrieben hast: Nirgends ein
GetCurrentDir, DirectoryExist (oder wie die Funtionen damals hießen <g>)
oder ParamStr(0)?

Nicht, daß ich wüsste.

Post by Heiko Rost
Zeigt ein simples, mit TP3 geschriebenes "Hello World"
die selben Probleme?

Leider nein. Das wäre wohl auch zu einfach gewesen. Zunächst mal Danke
für Deien Hinweis. Die Ursachenforschung interessiert mich aber später
doch noch. Nur jetzt ist erstmal "Feierabend" #-)

CU!
Ulrich

[Ulrich F. Heidenreich]

Post by Heiko Rost
Falls Du das Programm selber geschrieben hast: Nirgends ein
GetCurrentDir, DirectoryExist (oder wie die Funtionen damals hießen <g>)
oder ParamStr(0)?

Nein. Heute habe ich mal den Turbo Debugger auf die Fehleradresse
losgelassen. Es ist das "Rewrite (CON)" in der Initialisierungsroutine
einer kleinen Utility.tpu-Sammmlung, die auch von datimlog.pas mit
benutzt wird:

|begin
| ScreenSaved:=False;
| MacroActive:=False;
| Interrupted:=False;
| DateMask:=False;
| MacroDisable:=True;
| MenSel:=1;
| Assign (CON,'');
| Rewrite (CON);
|end.

Merkwürzig, sowas. Irgendwo in den Tiefen des DOS scheint mir dieses
Gerätefile(!) "CON" im aktuellen Verzeichnis erzeugt werden zu wollen,
was bei langen Verzeichnisnamen in die Hose geht.

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Nein. Heute habe ich mal den Turbo Debugger auf die Fehleradresse
losgelassen.

Auf die originale datimlog.exe oder ein neues Compilat?

Post by Ulrich F. Heidenreich
Es ist das "Rewrite (CON)" in der Initialisierungsroutine
einer kleinen Utility.tpu-Sammmlung, die auch von datimlog.pas mit
|begin
| ScreenSaved:=False;
| MacroActive:=False;
| Interrupted:=False;
| DateMask:=False;
| MacroDisable:=True;
| MenSel:=1;
| Assign (CON,'');
| Rewrite (CON);
|end.
Merkwürzig, sowas. Irgendwo in den Tiefen des DOS scheint mir dieses
Gerätefile(!) "CON" im aktuellen Verzeichnis erzeugt werden zu wollen,
was bei langen Verzeichnisnamen in die Hose geht.

Merkwürdig ist für mich eher, daß das plötzlich von einem Tag zum
anderen aufgetreten ist. Meine Vermutungen gehen in Richtung eines
Virenscanners, der die Datei immunisiert hat, oder eine Infektion des
Systems. Allerdings bin ich von beidem nicht so richtig überzeugt, weil
der Fehler dann nicht so genau in einer Programmzeile zu lokalisieren
wäre oder mehr Programme ein seltsames Verhalten zeigen müßten.

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Nein. Heute habe ich mal den Turbo Debugger auf die Fehleradresse
losgelassen.

Auf die originale datimlog.exe oder ein neues Compilat?

Das ist doch dasselbe :-) So schlau war ich nämlich auch, als der
Debugger an einer unerwarteten Stelle im Quelltext stoppte, das noch
einmal frisch zu kompilieren.

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Es ist das "Rewrite (CON)" in der Initialisierungsroutine
einer kleinen Utility.tpu-Sammmlung, die auch von datimlog.pas mit
|begin
| ScreenSaved:=False;
| MacroActive:=False;
| Interrupted:=False;
| DateMask:=False;
| MacroDisable:=True;
| MenSel:=1;
| Assign (CON,'');
| Rewrite (CON);
|end.
Merkwürzig, sowas. Irgendwo in den Tiefen des DOS scheint mir dieses
Gerätefile(!) "CON" im aktuellen Verzeichnis erzeugt werden zu wollen,
was bei langen Verzeichnisnamen in die Hose geht.

Merkwürdig ist für mich eher, daß das plötzlich von einem Tag zum
anderen aufgetreten ist.

Vermutlich bei der Verschiebung von "G:\dokumente\desktop\spamsinker"
nach "d:\spamsinker". Und wieder weg, nachdem ich auf Deinen guten Tip
hin "d:\spamsinker" in "d:\spamsink" umbenannte. Dort läuft das
Programm, was behufs datimlog.exe einen Zeitstempel ins Log schreiben
sollte. Nichts genaues weiß ich aber heute nicht mehr, weil sich dieser
Runtime-Error wohl in einem Log verewigte, in das ich nur alle
Jubeljahre mal reinschaue: Irgendwann stand da statt des Datums ein
Runtime-Error drin #-)

Post by Heiko Rost
Meine Vermutungen gehen in Richtung eines
Virenscanners, der die Datei immunisiert hat, oder eine Infektion des
Systems. Allerdings bin ich von beidem nicht so richtig überzeugt, weil
der Fehler dann nicht so genau in einer Programmzeile zu lokalisieren
wäre oder mehr Programme ein seltsames Verhalten zeigen müßten.

Ich hab's eindeutig eingrenzen können, indem ich das "Rewrite (CON)" mal
auskommentierte. Daanke nochmal für Deinen heißen Tip. Sonst hätte ich
mir die sprichwörtlichen Füße nach der Ursache wundgesucht.

CU!
Ulrich

[Stefan Reuther]

Post by Ulrich F. Heidenreich
|begin
| ScreenSaved:=False;
| MacroActive:=False;
| Interrupted:=False;
| DateMask:=False;
| MacroDisable:=True;
| MenSel:=1;
| Assign (CON,'');
| Rewrite (CON);
|end.
Merkwürzig, sowas. Irgendwo in den Tiefen des DOS scheint mir dieses
Gerätefile(!) "CON" im aktuellen Verzeichnis erzeugt werden zu wollen,
was bei langen Verzeichnisnamen in die Hose geht.

Ein Gerätefile "CON" wird hier nicht erzeugt. 'Rewrite' auf einen leeren
Dateinamen weist diesem Dateiobjekt den file-handle 1 (Standardausgabe)
zu, ohne weitere Systemaufrufe zu tätigen. Von daher kann der Laufzeit-
fehler nicht stammen.

Falls dieser Initialisierungsbereich zufällig mit $I+ übersetzt wurde,
kann die Fehlermeldung ein Überbleibsel aus einem anderen Bereich sein,
der mit $I- übersetzt wurde. Beispiel
var CON: Text;
begin
{$I-}
assign(CON, 'c:\afasdasdasd\foo');
rewrite(CON);
close(CON);
{$I+}
assign(CON, 'x.txt'); { oder assign(CON, '') }
rewrite(CON);
end.
bringt eine Fehlermeldung bei dem zweiten 'rewrite', obwohl dieses
erfolgreich war.


Stefan

[Ulrich F. Heidenreich]

Post by Stefan Reuther
Ein Gerätefile "CON" wird hier nicht erzeugt.

Für mich wohl schon. Irgendwo in den Tiefen der Utility.pas hatte ich
dadurch einen Filenamen zur Verfügung, der StdOut räpräsentiert. Also
genau das, was DOS als "con:" kennt.

Post by Stefan Reuther
'Rewrite' auf einen leeren
Dateinamen weist diesem Dateiobjekt den file-handle 1 (Standardausgabe)
zu, ohne weitere Systemaufrufe zu tätigen. Von daher kann der Laufzeit-
fehler nicht stammen.

Der kam aber eindeutig von dort. Wie sich durch auskommentieren und
recompilieren nachvollziehen ließ. Weiter möchte und brauche ich Dank
Heikos Hilfe nicht mehr rekonstruierenderweise in meinem fast 20 Jahre
altem Spaghetticode herumzusuchen. Außerdem ist das nicht Thema der
Gruppe hier.

CU!
Ulrich

[Stefan Reuther]

Post by Ulrich F. Heidenreich

Post by Stefan Reuther
Ein Gerätefile "CON" wird hier nicht erzeugt.

Für mich wohl schon. Irgendwo in den Tiefen der Utility.pas hatte ich
dadurch einen Filenamen zur Verfügung, der StdOut räpräsentiert. Also
genau das, was DOS als "con:" kennt.

Das ist Unsinn. 'con' ist eben nicht stdout, sondern die Konsole. Um
diese zu öffnen, hätte da aber 'Assign(CON, 'con');' stehen müssen. Da
stand aber 'Assign(CON, '');', und das verwendet stdout, egal, wohin es
umgeleitet wurde.

Post by Ulrich F. Heidenreich

Post by Stefan Reuther
'Rewrite' auf einen leeren
Dateinamen weist diesem Dateiobjekt den file-handle 1 (Standardausgabe)
zu, ohne weitere Systemaufrufe zu tätigen. Von daher kann der Laufzeit-
fehler nicht stammen.

Der kam aber eindeutig von dort. Wie sich durch auskommentieren und
recompilieren nachvollziehen ließ.

Kam er nicht. Durch Auskommentieren hast du das automatisch vom
Compiler eingefügte 'if InOutRes<>0 Then RunError(InOutRes)' entfernt.
Du hast damit nur das Symptom entfernt, nicht die Ursache.

Post by Ulrich F. Heidenreich
Weiter möchte und brauche ich Dank
Heikos Hilfe nicht mehr rekonstruierenderweise in meinem fast 20 Jahre
altem Spaghetticode herumzusuchen.

Tja, dann wird es dich eben demnächst wieder an einer völlig anderen
Stelle beißen.


Stefan