Nochmal Rexxutil.dll

[DonLucio]

Gibt es wirklich keine neuere Version von Rexxutil.dll als diese uralte vom 6.9.2000? Ich fahre AOS 5.0.4.

Habe aktuell schon wieder ein gravierendes Problem, mit eigenem Rexx-Sktript, das sich ausgiebig der Funktionen dieser DLL bedient:

Ich habe eine Log-Datei von inzwischen fast 5 GB Größe, die mir meine C-Partition zumüllt. Ich habe das aber gar nicht gemerkt, weil die Funktion SysFileTree() die Größe dieser Datei immer mit 1 angibt. Ebenfalls die (nicht-Rexxutil-) Funktion stream(file,"c","query size") zeigt mir 1 an.

Nur der Kommandozeilenbefehl dir zeigt die korrekte Größe: 4.812.852 K.

Wo liegt der Fehler? Kann es sein, dass eine über 20 Jahre alte Rexxutil.dll noch ihren Dienst tun kann? Wo gibt es eine neuere?

Gruß,
Lutz W.

[aschn]

Hier funktioniert es. Dein Minimalbeispiel fehlt.

[LotharS]

Nur der Kommandozeilenbefehl dir zeigt die korrekte Größe: 4.812.852 K.

Wo liegt der Fehler? Kann es sein, dass eine über 20 Jahre alte Rexxutil.dll noch ihren Dienst tun kann? Wo gibt es eine neuere?.

Mit Warp4 und HPFS wär das nicht passiert, irgendwie...
Die Rexxutil.dll outofthebox stammt noch unverändert aus Warp4-Tagen und liefert - basierend auf DosQueryPathInfo() - nur Dateigrößen <2GiB.
Erst das Warp4.5Toolkit kennt einen Weg darüber hinaus, Ergebnis als longlong (= long||ulong, aka int64). Wird so vom "DIR"-Komando abgebildet als auch unter (erst!) neueren XWP.
Workaround daher statt "Stream(...,'query size')" etwa: Stichworte "CMD /C DIR...", RxQueue, word() und optional local "set DIRCMD=".

Ob sich eines Tages mal jemand erbarmt und eine neuere Rexxuti2.dll aus den alten Sourcen schreibt und alle bisher aufgelaufenen Abhängigkeiten und Wünsche einbaut, und zu beiden Support gibt, wer weiß....

[DonLucio]

Hier funktioniert es.

Tatsächlich?? Mit derselben Rexxutil.dll von 2000?

Dein Minimalbeispiel fehlt.

Hier kommt der Dreizeiler:

Code: Alles auswählen

Call SysFileTree "C:\var\log\log.ndpsmb","files.", "F";
LogfileSize = word(files.1,3);
say "LogfileSize="LogfileSize"!";

Als Ausgabe erhalte ich:

Code: Alles auswählen

LogfileSize=1!

Zum Hintergrund:
Es handelt sich um die SAMBA-Logdatei, die zu führen mir der ArcaNoae-Support aufgegeben hat, um den Problemen, die ich mit dem Arcamapper sporadisch habe, auf die Spur zu kommen. Und diese Datei wächst mit der Zeit (und der Intensität meiner Samba-Aktivitäten). Deswegen lösche ich sie bei Erreichen einer Größe von 1 GB. Zur Überwachung habe ich einen solchen Dreizeiler geschrieben, der aber leider ab einer bestimmten Größe (2 GB) immer 1 liefert.

Also wenn's nicht an meiner veralteten Rexxutil liegt, werde ich halt den von LotharS vorgeschlagenen Workaround via "cmd /C dir ..." gehen müssen. Very unelegant ...

Gruß,
Lutz W.

[aschn]

Ja, jetzt sehe ich es auch, dass es um Riesendateien geht. Du könntest mal die Version von Michael Greene probieren, die mit OW kompiliert wurde. Er hatte versucht alles aus rexxutil.dll kompatibel nachzubilden. Wenn das klappen sollte, dann würd ich die aber nur für das Projekt verwenden und anschließend wieder entladen, weil es unwahrscheinlich ist, dass irgendetwas ohne mehrjähriges Testen 100 % kompatibel ist.

(Nebenbei: Ich mach grundsätzlich nichts mit Riesendateien und OS/2. Ich hab auf dem System nicht mal so eine Datei.)

[LotharS]

Hier kommt der Dreizeiler:
...
... der aber leider ab einer bestimmten Größe (2 GB) immer 1 liefert.

.. und wenn's auf einem Netzlaufwerk lag, dann sogar gerne mit Ergebnis = 0, warum auch immer (>2GB gab's in HPFS ja nicht...). Gleiche Symptome auf eCS2.1 und dessen altem XWP im Fileobjekt-Kontextmenü. Hatte ich auch erst nach 3 Jahren mit mal dickeren Testfällen gemerkt und in meinem "LSZipWizard" (@Hobbes) gefixed, dank reichlich Corona-Home-Relax

[DonLucio]

Ja, jetzt sehe ich es auch, dass es um Riesendateien geht. Du könntest mal die Version von Michael Greene probieren, die mit OW kompiliert wurde.

Diese Version hatte ich mal irrtümlich in meinem System, ohne es zu wissen (wie hier im Forum beschrieben). Habe damit aber andere Probleme gehabt, z.B. das Datums-("Millenium"-)Problem. Ich rate ab davon, diese Vesion für irgendwas zu verwenden.

Ich mach grundsätzlich nichts mit Riesendateien und OS/2. Ich hab auf dem System nicht mal so eine Datei.

Hmm .... ich eigentlich auch nicht. Aber bei Log-Dateien, die sich im Laufe der Zeit immer mehr füllen, kann man es kaum verhindern. Popuplog.os2 ist ja auch so ein Beispiel. Nur dass es (hoffentlich) sehr lange dauert, bis diese Datei> 2 GB erreicht

Gruß,
Lutz W.

[aschn]

Aber bei Log-Dateien, die sich im Laufe der Zeit immer mehr füllen, kann man es kaum verhindern. Popuplog.os2 ist ja auch so ein Beispiel.

Ja, wenn mich interessiert, was da drin steht, dann lösch ich die vorher, bevor ich Ergebnisse sammel. Die Einträge alleine nützen einem ja nichts, wenn man nicht die genaue Aktion dazu kennt.

Womit man etwas anfangen kann, das endet bei einer Größe von einigen MB. Von Hand so etwas zu durchsuchen ist schon fast unmöglich. Aber einige GB? (Es gibt ja nicht viele OS/2-Editoren, die so eine Datei öffnen können.) Meine warpin.log ist z.B. 20 MB groß und hat 300 000 Zeilen. Was soll ich mit den Einträgen aus 2020?

Wenn Du alte Log-Dateien unbedingt behalten willst, dann könntest Du ja mehrere Generationen aufbewahren und die z.B. wöchentlich umkopieren/verschieben.

[erdmann]

Hier Mal eine ganz pragmatische Lösung: Vergleich doch einfach die Dateigröße zwischen zwei Aufrufen deines Programms. Wenn die Differenz negativ wird, weißt du dass deine Datei offensichtlich die 2 GB Grenze überschritten haben muss. Die alte Größe (zum Vergleichen) kannst du dabei als EA in der REXX Skriptdatei selbst abspeichern.