Fehler in RexxUtil?

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
User avatar
DonLucio
Posts: 661
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Fehler in RexxUtil?

Post by DonLucio »

Das Problem macht mir bei meiner täglichen Datensicherungs-Prozedur große Probleme:

Ich habe hier eine alte Datei dem Jahre 1998. Die wird bei jedem Datensicherungslauf regelmäßig mit verarbeitet, sprich mit aufs Datensicherungsmedium geschrieben, obgleich die Dateiversion auf dem Zielmedium jünger ist (z.B. 15. Juli 2021, also Datum meiner letzten Datensicherung).

Das wäre vielleicht weniger tragisch, wenn nicht diese Datei (und noch ein paar weitere) eine Videodatei wäre mit einer Größe von knapp 2 GB.

Also habe ich mich mal auf die Suche nach der Ursache gemacht und festgestellt: Die Ermittlung des Dateidatums mittels SysGetFileDateTime() aus RexxUtil.dll liefert bei der Datei von 1998 ein Datum "1.01.2098" (Uhrzeit 3:26:50 ist unauffällig).

Konsequenterweise zeigt der Kommandozeilenbefehl "dir" ebenfalls als Jahr 2098 an.

Irritierenderweise aber wird das Datum aus einer Linux-Umgebung heraus mit "1.01.1970" angezeigt (Uhrzeit dieselbe). Das ist aber genauso falsch wie 2098.

Es betrifft leider eine nicht ganz geringe Anzahl von Dateien, die zusammengenommen mein Datensicherungs-Procedere mit etwa 36 GB Daten belasten. Täglich. Deswegen meine Frage:

Gibt es vielleicht eine neuere Version von RexxUtil, die diesen "Milleniums"-Fehler nicht enthält?

Datum meiner aktuellen (und einzigen) RexxUtil.dll: 7-03-2008 3:40:14.


Danke,
Lutz W.

User avatar
LotharS
Posts: 782
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS »

DonLucio wrote:
Sat 17. Jul 2021, 17:27
Datum meiner aktuellen (und einzigen) RexxUtil.dll: 7-03-2008 3:40:14.
Woher stammt denn diese? Hier in eCS und ArcaOS: "6.09.00 12.42 68.119 0 a--- REXXUTIL.DLL"

Was wird denn im Kontextmenü Eigenschaften>Datei angezeigt? (Für dort korrekte Dateigrößen >2GB mag ein XWP-Update angesagt sein).

Nebenbei: Selber benutze ich oldschool sowas wie "infotime = stream( filename, "C", "QUERY DATETIME" )" und drösele das Resultat zur y2k-Anzeige auf (Schwelle bei jj=80).

Wenn aber schon das einfache "dir"-Kommando Unfug liefert: Wenn dasPhänomen ja nur "ein paar" Dateien betrifft: Wenn eine zB. xxx.zzz neu gespeichert wird als xxx1.zzz, wie sehen die Datümer dann aus? Mit der Idee, bestenfalls ginge letztere noch einmal ins Backup und dann ist Ruhe...

User avatar
DonLucio
Posts: 661
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

LotharS wrote:
Mon 19. Jul 2021, 13:33
DonLucio wrote:
Sat 17. Jul 2021, 17:27
Datum meiner aktuellen (und einzigen) RexxUtil.dll: 7-03-2008 3:40:14.
Woher stammt denn diese? Hier in eCS und ArcaOS: "6.09.00 12.42 68.119 0 a--- REXXUTIL.DLL"
Ja, das war auch meine ursprüngliche Version (AOS 5.0.4). Ich habe dann aufgrund dieses Datumsproblems eine neuere Version gesucht und bin bei Hobbes fündig geworden. Scheint aber außer in der Dateigröße (ein paar Bytes größer) keine signifikanten Änderungen zu beinhalten.

LotharS wrote:
Mon 19. Jul 2021, 13:33
Was wird denn im Kontextmenü Eigenschaften>Datei angezeigt?
Wenig überraschend: 2098.01.01 (Dateigröße < 100 MB).

LotharS wrote: Nebenbei: Selber benutze ich oldschool sowas wie "infotime = stream( filename, "C", "QUERY DATETIME" )" und drösele das Resultat zur y2k-Anzeige auf (Schwelle bei jj=80).
OK, das ist ja die seinerzeit übliche Strategie, um einstellige Jahreszahlen millenium-fähig zu machen. Wieso aber kennt mein RexxUtil diese Methode offenbar nicht?

LotharS wrote:Wenn eine zB. xxx.zzz neu gespeichert wird als xxx1.zzz, wie sehen die Datümer dann aus? Mit der Idee, bestenfalls ginge letztere noch einmal ins Backup und dann ist Ruhe...
Ok, das wäre ein brauchbarer Workaround. Ebenso wie die alternative Methode, zur Festellung der Kopiernotwendigkeit nicht das Dateidatum, sondern das Archivbit zu verwenden.

Mir geht's aber eigentlich grundsätzlich um die Frage nach einer (neuen) fehlerfreien Version von RexxUtil, weil ich damit extrem intensiv arbeite (wer tut das nicht:-) ).

Die scheint's aber nicht zu geben.

Gruß,
Lutz W.

erdmann
Posts: 442
Joined: Mon 4. Jan 2016, 14:36

Post by erdmann »

Rexxutil kann da gar nichts machen. Offensichtlich ist in den Dateisystemattributen ein Jahr "0" verzeichnet. Dann reimen sich OS/2 und Linux zusammen, was das denn für ein Jahr sein soll und kommen offensichtlich zu unterschiedlichen Ergebnissen.
Der Fix ist, die Datei von A nach B zu kopieren, dann A zu löschen und B wieder zurück zu kopieren. Oder ein kleines Programm zu schreiben, welches Uhrzeit und Datum direkt setzt/erzwingt. Letzteres ist einfach (es gibt eine API Funktion dafür).

User avatar
LotharS
Posts: 782
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS »

DonLucio wrote:
Mon 19. Jul 2021, 17:25
LotharS wrote:
Mon 19. Jul 2021, 13:33
Was wird denn im Kontextmenü Eigenschaften>Datei angezeigt?
Wenig überraschend: 2098.01.01 (Dateigröße < 100 MB).
Die dort angezeigten Datei-Eigenschaften halte ich für die technisch zutreffenden. Folglich scheint Deine RexxUtil insoweit sogar ok *). Außerdem gibt es drei Datums: Erstellung, letztes Schreiben (erscheint unter 'dir'), letzter Zugriff.
Auch wenn die Datei inhaltlich ursrünglich aus 1998 stammt, tippe ich auf auf irgendein historisches Problem beim Ab- oder Umspeichern der Datei. Denn auch '....01.01' sieht wohl suspekt aus. Möglicherweise ein ehemals nur temporäres y2k-Umstellungsding?

In Linux ist der 1.1.1970 = Datum 0, dh. von dort bis heute sind es soundsoviele Tage. Spekulation, ob da zu '2098' vielleicht was übergelaufen ist....

*) IMHO würde ich von solcher "experimentellen Version" (lt. Hobbes) generell abraten. Der Autor benutzt lt. Readme OREXX-Sourcen, und bekanntlich ist OREXX immer noch buggy und keiner kümmert sich mehr darum. Allenfalls was für den eigenen Privatgebrauch, denn der Rest der Gemeinde wird üblich die offiziellen DLLs nutzen.

User avatar
DonLucio
Posts: 661
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

erdmann wrote:
Mon 19. Jul 2021, 19:02
Rexxutil kann da gar nichts machen. Offensichtlich ist in den Dateisystemattributen ein Jahr "0" verzeichnet. Dann reimen sich OS/2 und Linux zusammen, was das denn für ein Jahr sein soll
Das mit dem "Zusammenreimen" im Falle unzureichender Information in den Dateisystemattributen trifft wohl zu. Aber zumindest RexxUtil beweist dabei keine besondere Intelligenz. Eine einfache Plausibilitätsprüfung könnte zu anderen, korrekten Ergenissen führen: "Datum letzter Zugriff 15.Juli 2021"; "Datum Erstellung: 1.1.2098", also 77 Jahre *nach* seinem letzten Zugriff?

Aber selbst wenn (aufgrund Dateisystem-Beschränkung) nur das Erstellungsdatum verfügbar ist: Die einfache Überlegung, dass als Dateierstellungsdatum niemals ein Datum in der Zukunft in Frage kommt, sollte ausreichen, um in meinem Falle das korrekte Datum 1998 zu liefern.

Mit Hilfe dieses "genialen" Algorithmus haben vor etwa 22 Jahrem ganze Legionen von Programmierern das damalige Milleniums-Problem bekämpft und sich dumm und dusselig damit verdient :D

erdmann wrote:Der Fix ist, ... ein kleines Programm zu schreiben, welches Uhrzeit und Datum direkt setzt/erzwingt. Letzteres ist einfach (es gibt eine API Funktion dafür).
So werd' ich's wohl auch machen.

Gruß,
Lutz W.

erdmann
Posts: 442
Joined: Mon 4. Jan 2016, 14:36

Post by erdmann »

Ich weiss nicht so recht, ob es so einfach ist.

Manche Dateisysteme sind nicht in der Lage, das Jahr absolut abzuspeichern sondern nur relativ zu einem Anfangsdatum (FAT16). Andere können das aber (sehr wahrscheinlich HPFS und JFS). Wenn da dann 0 drin steht ist klar, dass das in beiden Fällen schlicht Nonsense ist (FAT16 geht ja von 1970 aus, so alte Dateien hat wahrscheinlich niemand mehr). Die Frage ist dann, ob man sich mit dem Raten Mühe geben sollte oder nicht.
Für mich sieht dein Fall so aus, als ob die Dateisystemattribute z.T. zerschossen sind. Die richtige Lösung ist es, sie zu reparieren und nicht, einen Workaround zum eigentlichen Problem zu finden.

Andi B.
Posts: 574
Joined: Tue 24. Dec 2013, 16:40

Post by Andi B. »

DonLucio wrote:
Tue 20. Jul 2021, 14:08
.....Die einfache Überlegung, dass als Dateierstellungsdatum niemals ein Datum in der Zukunft in Frage kommt, sollte ausreichen, ....
Schon beim einfachen Beispiel einer leeren CMOS Batterie, stimmt deine Theorie nicht mehr. Ganz zu schweigen von verschiedenen Zeitzonen oder Problemen von Zeitsync Tools.....

User avatar
LotharS
Posts: 782
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS »

DonLucio wrote:
Tue 20. Jul 2021, 14:08
Das mit dem "Zusammenreimen" im Falle unzureichender Information in den Dateisystemattributen trifft wohl zu. Aber zumindest RexxUtil beweist dabei keine besondere Intelligenz. Eine einfache Plausibilitätsprüfung könnte zu anderen, korrekten Ergenissen führen: "Datum letzter Zugriff 15.Juli 2021"; "Datum Erstellung: 1.1.2098", also 77 Jahre *nach* seinem letzten Zugriff?
Warum sollte RexxUtil auch zusätzliche "Intelligenz" besitzen. Ich wette, es benutzt geradewegs DosQueryFileInfo(), liest stumpf ab was es in den Dateiattributen tatsächlich findet und reicht es unverfälscht hoch. Mehr als dokumentiert sollte eine Funktion nicht liefern, denn wie sollte man sich auf sie auch verlassen oder Abweichungen/Bugs finden. Der Entwickler mag dann selber entscheiden, ob ihm die Ist-Zustände wie gewünscht erscheinen oder nicht.

Mit DosSetFileInfo() ließe sich das Datum wohl reparieren, oder (simpel) wie erwähnt durch Neuspeichern und zurückbenennen das Backup-Problem umgehen. Was in den "paar" Dateien zu den korrupten Attributen geführt hat, sei's dann drum, ließe sich in einer begleitenden txt-Datei erzählen. Ob wegen temporär y2k, Bios oder Verschieben zwischen Dateisystemen: wer weiß, Vergessen hilft manchmal ganz gut :)

Nebenbei: der Autor hätte sauberer daran getan, seinen RexxUtil-"Clone" unter anderem Namen zu liefern. Oder wenn's ihm um weitere Funktionen gegangen wäre, eine separate dll anzubieten, tun andere ja auch.

aschn
Posts: 1157
Joined: Wed 25. Dec 2013, 22:47

Post by aschn »

LotharS wrote:
Tue 20. Jul 2021, 18:05
Nebenbei: der Autor hätte sauberer daran getan, seinen RexxUtil-"Clone" unter anderem Namen zu liefern.
Wenn Ihr die Version von Michael Greene meint: Das ist doch nur eine Testversion. Dass sie nicht anders heißt, macht es Leuten einfacher sie zu testen. Es ging ja darum, dass möglichst alles zur IBM-DLL kompatibel ist. Ich hatte sie 2008 als rexxutil-clone gesichert. OK, die Archivdatei hätte Michael anders nennen können.
Andreas Schnellbacher

User avatar
ak120
Posts: 1015
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 »

erdmann wrote:
Tue 20. Jul 2021, 14:34
Ich weiss nicht so recht, ob es so einfach ist.

Manche Dateisysteme sind nicht in der Lage, das Jahr absolut abzuspeichern sondern nur relativ zu einem Anfangsdatum (FAT16). Andere können das aber (sehr wahrscheinlich HPFS und JFS). Wenn da dann 0 drin steht ist klar, dass das in beiden Fällen schlicht Nonsense ist (FAT16 geht ja von 1970 aus, so alte Dateien hat wahrscheinlich niemand mehr).
Bei der FAT-Implementierung unter DOS und abgeleiteten Systemen dürfte es schwierig sein, ein Datum vor dem 1.1.1980 0:00 Uhr als Normalbenutzer zu erzeugen. Eine Umrechnung aus der Unix-Zeit (ab 1.1.1970) nach FAT ist selbst näherungsweise äußerst problematisch.
Die Frage ist dann, ob man sich mit dem Raten Mühe geben sollte oder nicht.
Für mich sieht dein Fall so aus, als ob die Dateisystemattribute z.T. zerschossen sind. Die richtige Lösung ist es, sie zu reparieren und nicht, einen Workaround zum eigentlichen Problem zu finden.
Wegen der ungenauen Angaben im ursprünglichen Beitrag, würde ich auch dieser Vermutung zustimmen. Theoretisch wären noch andere Ursachen denkbar. Aber bei der Verwendung eines rexxutil.dll-Nachbaus (bei gleichzeitiger Nutzung einer anderen C-Laufzeitbibliothek) trägt es nicht gerade zur Eingrenzung bei.

aschn
Posts: 1157
Joined: Wed 25. Dec 2013, 22:47

Post by aschn »

Richtig. Wenn auch "DIR" das gleiche anzeigt, dann kann's ja auch schlecht an einer REXX-DLL liegen. Diese greift genauso wie "DIR" auf die von Lothar erwähnten Funktionen zu. Die Daten dafür kommen vom Dateisystem (und dessen Treiber). Was an der Kette defekt ist (oder mal war, wie Lothar geschrieben hat), will man nicht raten. Gaerade, wenn es die einfache Möglichkeit gibt, das Datum mit DosSetFileInfo zu ändern.
Andreas Schnellbacher

User avatar
LotharS
Posts: 782
Joined: Sun 29. Dec 2013, 20:07
Location: Düsseldorf

Post by LotharS »

Ein Blick in die dem RexxUtil-Clone beigefügten Sourcen bestätigt meine Vermutung (nagut, DosQueryPathInfo() mit gleichem Resultat).

@Lutz: Was passiert nach einem Reparaturversuch per REXX mittels (neuer) SysSetFileDateTime() ?

User avatar
DonLucio
Posts: 661
Joined: Sun 29. Dec 2013, 01:14
Location: Hamburg

Post by DonLucio »

LotharS wrote:
Wed 21. Jul 2021, 09:39
@Lutz: Was passiert nach einem Reparaturversuch per REXX mittels (neuer) SysSetFileDateTime() ?
Ein Rexx-Dreizeiler, runtergehackt in 2 Minuten, hat das Problem behoben. Sogar Linux erkennt die Datümer jetzt korrekt als "1998".

Wobei: "Korrekt" ist auch nicht ganz richtig. Wie ich inzwischen festgestellt habe, stammen die Problem-Dateien (Videos) aus einem Camcorder, den ich erst im Jahre 2002 gekauft habe. Seinerzeit irgendwie auf Windows-95 gezogen und dann ... hin und her .. weiß nicht mehr. Sind die irgendwie, auf Umwegen über Iomega-Zip, CDs etc. in meiner OS/2-Welt gelandet.

Egal, Problem gelöst.

Für Interessierte hier der Rexx-"Dreizeiler":

Code: Select all

/* Korrigieren File-Dates	*/
InDir = "x:\yyyy\zzz\....";
Heute = Date("S");		/* "2021-07-21"		*/

ok = SysFileTree(InDir"\*.mp?", "files.", "F");		/* hier nur Videos		*/
do i = 1 to files.0
   File = files.i;

   FS = subword(File,5);	/* Filespec		*/
   FN = filespec("name",FS);
   DateCreated  = word( SysGetFileDateTime(FS,"C"), 1);	/* abgreifen YYYY-MM-DD	*/

   if DateCreated > Heute then do
      NewDate = "19" || word( substr(DateCreated,3),1);
      ok = SysSetFileDateTime(FS, NewDate);
      if (ok<>0) then 
	 say "Error setting new filedate for "FN", RC="ok;
   end;

end;
exit;