Fehler in GetFDate?

[KKraft]

Hallo,

falls das nicht der richtige Ort ist, um Bugs zu melden, bin ich für einen entsprechenden Hinweis dankbar - danke!

Unter XP,SP2 mit XProfan 11.2 sind beim Lauf eines selbstgeschriebenen Programmes immer wieder mal Abstürze aufgetreten, die sich zu einem Aufruf von GetFDate zurückverfolgen ließen. Als gemeinsame Eigenschaft der auslösenden Dateien stellte sich das Datum 31.12.79 heraus.

dir im DOS-Fenster zeigte das erwähnte Datum an. Der Explorer zeigte bei den betreffenden Dateien kein Datum an, aber keiner der beiden stürzte ab.

Nach Ändern des Datums per touch-Programm trat das Problem nicht mehr auf. Meine Anregung wäre also neben Beseitigung des wahrscheinlichen Bug eine SetFDate bzw. SetFTime-Funktion


Gruß
Karl

[Jac de Lad]

Ich glaube nicht dass es ein Bug ist, aber vielleicht gibts einen Workaround.

[Frabbing]

Hallo Karl,

um einen Bug zu melden empfiehlt es sich, einen möglichst kurze Testcode bereit zu stellen, in dem der Fehler auftritt. Oftmals merkt man dann schon, das der Bug in einem großen Programm an ganz anderer Stelle auftritt.

[KKraft]

Hier ist der gewünschte Beispielcode:

Bis auf Datum/Zeit identische Dateien ---------------

Y:\tmp>dir *.ini

Verzeichnis von Y:\tmp

31.12.1979 23:00 548 deutsch.ini
28.02.2011 17:48 548 deutsch2.ini

Code -----------------------------------------------

cls
chdir "y:\\tmp"
print "getfdate deutsch2.ini ",getfdate$("deutsch2.ini")
print "getfdate deutsch2.ini ",getftime$("deutsch2.ini")
waitkey
print "getfdate deutsch.ini ",getfdate$("deutsch.ini")
print "getfdate deutsch.ini ",getftime$("deutsch.ini")
waitkey
end

Daraus eine Exe erzeugt und aufgerufen

ergibt die Ausgabe ----------------------------------

getfdate deutsch2.ini 20110228
getfdate deutsch2.ini 17:48:42:00
<Tastendruck>
getfdate deutsch.ini

dann erscheint das "Profan-Runtime (11.2a) hat ein Problem festgestellt
und muß beendet werden"-Fenster. Das Gleiche passiert auch, wenn
die Ergebnisse von getfdate$ bzw. getftime$ nicht ausgegeben,
sondern Variablen zugewiesen werden. Im Interpreter-Mode
werden statt des Absturzes falsche Werte für die Datei
deutsch.ini ausgegeben.

Wird das Datum der Datei vom 31.12.1979 auf's aktuelle
gesetzt (so wie bei deutsch2.ini schon geschehen), ist der
Spuk vorbei.

Gruß
Karl

[Bangkok]

Ja, da scheint was in Profan nicht zu stimmen, auch X2 stürzt ab. Mit der API und dem Explorer wird es richtig angezeigt. Welches Datum zeigt Getfdate$ eigentlich an ?
Da ich das Datum ja manuell ändern musste zeigt mein Tool mit API alles richtig an.

[Volkmar]

Hallo allerseits

Wo kommt das Datum 31.12.79 denn her? Oder genauer gefragt, was bedeutet die 79? Soll die für 1979 stehen? Dann sind Fehler auf jeden Fall zu erwarten. Das Datum in Dateien wird in einem sogenannten gepackten Format abgelegt. Und das ist erst beginnend mit dem Datum 01.01.1980 definiert!

Quelle:
Ray Duncan
Professionell programmieren mit MS-Macro-Assembler
S.127 ff

Gruß Volkmar

[KKraft]

Hallo Volkmar,

die Datei deutsch.ini ist Bestandteil eines uralten DOS-Entwicklungspaketes und hatte einfach dieses Datum. Vielleicht gab's unter DOS ja mal eine weiter zurückreichende Dateidatierung?

Mittlerweile habe ich noch mehr Dateien mit einem Datum vor 1980 gefunden, die bei Aufruf von getfdate$ bzw. getftime$ ebenfalls zum Crash führen.

Mag ja sein, daß das eigentlich kein gültiges Datum ist, aber sowohl dir im DOS-Fenster als auch der Explorer tolerieren es ohne Absturz.

Gruß
Karl

[Volkmar]

Hallo KKraft

Irgendwie überrascht mich das aber jetzt. MS-DOS in der Version 1.0 ist erst im Jahre 1981 erschienen. Daten vor 1981 können eigentlich nur MS-DOS-Komponenten selbst sein, die eben schon vor dem Verkaufsstart erstellt wurden. (Sonst hätte man es ja nicht verkaufen können)
Für das Jahr sind genau 7 Bit in einem 2 Byte großen Feld vorgesehen. Wenn dieser 7-Bit-Wert 0 hat, wird das Jahr 1980 angezeigt u.s.w.. Denkbar ist nun natürlich, mit negativen Werten auch rückwärtige Daten darzustellen. Aber das wären dann Dateien, die auf jeden Fall illegal sind, weil das Erstellungsdatum auf eine Zeit verweist, als es noch gar kein MS-DOS gab.
Ich gehe jetzt einfach mal davon aus, daß diese negativen Werte von einigen Funktionen toleriert werden, aber eben nicht von der Funktion, die XProfan zum Auslesen des Dateidatums verwendet. Warum jemand ein solches Dateidatum setzt, ist mir allerdings unverständlich.
Möglicherweise findet Roland einen Weg, das Dateidatum auch auf andere Weise auszulesen, aber als Fehler in XProfan würde ich das derzeitige Verhalten eher nicht ansehen.
Da durchaus auch mit anderen Programmen oder einer neueren Windowsversion Probleme mit diesen Dateien auftreten können (nicht zwingend müssen), würde ich Dir empfehlen, das Datum auf einen Wert nach dem 1.1.1980 zu setzen.

Gruß Volkmar

[Bangkok]

Ich stehe auf dem Standpunkt, sobald und solange Windows das Datum erlaubt und eine Programmiersprache dabei abstürzt liegt ein Fehler vor, denn dann wird irgend eine ungeeignete Ausleseroutine angewendet, da die Windows API das Datum zweifellos noch unterstützt. Es wird zwar sehr selten vorkommen, dass so ein Datum verwendet wird, aber vielleicht ändert ja jemand aus irgendwelchen Gründen ein Datum von Hand oder macht einen Fehler beim Einstellen und schon stürzt ein Programm ab. Man stelle sich vor Totalcommander oder ein anderer Commander würden beim einlesen der Dateien abstürzen.

[RGH]

Hallo,
es ist hier offensichtlich die Delphi-Funktion FileDateToDateTime(), die mit diesem ungültigen Dateidatum nicht klarkommt. Das niedrigste gültige Dateidatum in MS-DOS und Nachfolgebetriebsystemen ist der 1.1.1980.
Ich könnte hier also für eine der nächsten Versionen am Quellcode der Delphifunktiom 'rumschrauben oder auf die Funktion verzichten und den Dateizeitpunkt anders (etwa per API) bestimmen. Für Dateifunktionen hatte ich bislang ausschließlich Delphi-Funktionen verwandt, damit diese z.B. auch in der DOS-Version von Profan² 7 funktionierten. Aber da DOS inzwischen Geschichte ist ...

Gruß
Roland

[Bangkok]

Hallo Roland,

würde ich so machen, denn die DOS-Version von Profan² 7 ist ja längst Geschichte und es gibt ja danach keine Dos-Version von Profan mehr und wenn der Name der Funktion gleich bleibt ist ja egal was dahinter steckt. Dateifunktionen sollten meiner Meinung nach auf keinen Fall zu einem Absturz führen.

[KKraft]

Hallo,

die Auflösung der Frage im Titel ist sehr platt: weil die betreffenden Dateien
tatsächlich vor 1980 erzeugt wurden, aber nicht auf einem PC!

Die Dateien befanden sich in einem von meinem Programm erzeugten "Repository", in dem sie nach anderen Kriterien als den ursprünglichen Verzeichnisbäumen untergebracht sind. Alle Dateien mit einer Extension in einem Verzeichnis wäre z.B. so ein anderes Kriterium.

Deshalb fiel mir nicht gleich auf, daß die 12 Dateien von über 240.000, bei denen die Abstürze in getfdate$ auftraten, alle aus einem ursprünglichen Verzeichnis stammen.
Wie ich mittlerweile gesehen habe, handelt es sich beim Inhalt dieses Verzeichnisses nicht um ein DOS-Entwicklungspaket, sondern ein DOS-Paket zum Datenaustausch PC <-> Psion 3er-Serie.
Im Verzeichnis befinden sich neben der eigentlichen DOS-Transfersoftware auch Psion-Dateien, die mit der PC-Software über die serielle Schnittstelle auf dem Psion installiert werden. Genau diese haben das auf dem PC ungültige Datum.

Offiziell wurde die Firma Psion im Jahr 1980 gegründet, aber wahrscheinlich aufgrund schon vorhandener, eben vor 1980 entwickelter Produkte, deren Software dann eben auch Dateien mit einem früheren Datum enthält.

Diese Dateien wurden dann mit irgendeinem Transferprogramm, dem es egal ist, ab wann die PC-Zeitrechnung beginnt, auf einen PC transferiert und an Psion-Kunden ausgeliefert, die sie wiederum von Ihrem PC
auf dem Psion installieren konnten.

Das bedeutet aber, daß es gute Chancen gibt, außer bei mir auch auf anderen Windows-PCs auf - auf dem Windows-PC - ungültige Dateidaten von vor 1980 zu stoßen, denn sowohl in Banken als auch an Unis (das UNIX-Universum, ab 1969) gibt es bergeweise aufhebenswerte Software von vor 1980, die letztlich zwecks Sicherung auch auf Win-PCs landen dürfte.

Da ich einige Jahrzehnte professionell Software entwickelt habe,
behaupte ich mal, daß einige Entwickler entsprechender
Transerprogramme dank etwas Zeitdruck schlichtweg vergessen haben werden, daß ihr Programm Dateidaten so umsetzen sollte, daß ein auf dem PC gültiges Datei-Datum dabei herauskommt, zumal dir und der Explorer ja auch so klarkamen.

Also bleibt, wie Bangkok schon anmerkte, nur die Möglichkeit, getfdate$ und getftime$ ebenfalls krisenfest zu machen, wenn XPROFAN nicht das Image einer Neigung zu mysteriösen Abstürzen erhalten soll.

Gruß
Karl

[Volkmar]

Hallo allerseits

@Bangkok, da möchte ich Dir nicht wiedersprechen.
Ich habe in der Sache noch etwas weiter gesucht. Der Explorer zeigt bei solchen Daten in der Ansicht "Details" beim Dateidatum nichts an, die Spalte bleibt leer, weil in der Datenstruktur der Datei dann einfach zwei Nullbytes stehen. Nur auf der Registerkarte Eigenschaften wird das "illegale" Datum korrekt angezeigt. Und genau an diesem Nichts scheitert XProfan bei entsprechendem Errorlevel mit der Meldung "Falscher Typ für @DToC$" oder verabschiedet sich gleich. Roland wird dann wohl eine andere Möglichkeit finden, wie er schon schrieb.
Hat etwas gedauert, ein Tool zum Ändern des Datums versuchte diese 7-Bit-Darstellung aus DOS-Zeiten korrekt umzusetzen und dann hatte ich ein Datum im Jahre 2107.

Gruß Volkmar

[Bangkok]

Die Umwandlung mit DToC$ hatte ich noch gar nicht probiert, da getfdate$ allein schon abstürzt.

Mein uraltes Tool, das ich vor langer Zeit, ich glaube mit Profan 7.6 geschrieben habe, liest und schreibt das ungültige Datum ohne Probleme. Basiert rein auf API.

[Volkmar]

Hallo

Klar, die Umwandlung DToC$ kannst Du auch nicht probieren, weil es vorher schon scheitert. Aber wenn ich mal per Errorlevel ein bischen rumspiele, dann stürzt das nicht gleich ab sondern bringt diese Meldung und bricht dann ab. Kommt letztendlich auf das Gleich raus, aber ich wollte einfach mal wissen, was da schief läuft und habe alle möglichen Experimente gemacht, nachdem ich erst mal so ein Datum setzen konnte.
API ist eben doch der bessere Weg. Da habe ich auch wieder was bei gelernt. Man darf also auch Delphi nicht trauen.

Edit: Einfach nur Errorlevel hochsetzen reicht natürlich nicht. Habe die Eingangsdaten da über ASM ausgelesen und dann bei der Auswertung nicht direkt die Bytes angezeigt sondern dann so weiter, als wären da gültige Daten. So kommt die Fehlermeldung zustande.

Gruß Volkmar