Probleme mit großer Datei

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Antworten
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Probleme mit großer Datei

Beitrag von DonLucio »

Ich blicke nicht mehr durch. Gab's nicht mal eine max. Dateigröße im OS/2, die bei 2 GB lag? Oder waren es 4 GB. Oder gibt es diese Begrenzungen im modernen (!) Dateisystem JFS nicht mehr?

Mein konkreter Fall gibt mir Rätsel auf:
Es handelt sich um eine 3,9 GB große MP4-Datei, aus einem handelsüblichen Camcorder.
Die Datei ist über einen USB-Stick (mit DFSee auf FAT32 formatiert) aus einem Windows-System zu mir in mein ArcaOS-System gekommen. Liegt dort auf einer JFS-Partition.

Die Datei kann ich mit VLC anschauen, fehlerfrei. VLC sagt: 15 Minuten 25 Sekunden lang. Leider kann VLC aber keine Teile ausschneiden. Dafür gibt es aber ja ffmpeg, mit dem ich schon jede Menge MP4-Dateien bearbeitet habe.

Leider scheitert ffmpeg an dieser großen Videodatei. Bricht ab mit kryptischen Fehlermeldungen. Liegt's an der Dateigröße?

Um die genaue Anzahl Bytes zu ermitteln, schreibe ich ein Zweizeiler-Rexx mit der Funktion SysFileTree(), die bekanntlich u.a. die exakte Dateigröße auswirft, Ergebnis im vorliegenden Fall: Dateigröße 1. Sehr merkwürdig.

Auf der Kommandozeile per dir-Befehl sehe ich aber die korrekte Dateigröße: 3.887.758 K

Hier wurde ja schon mehrfach das Problem thematisiert, dass SysFileTree() historisch veraltete Basis-Funktionen des zugrundeliegenden OS verwendet. Offenbar leidet ffmpeg an eben diesen selben Unzulänglichkeiten.

Was die Sache aber vollends verrückt macht, ist die Tatsache, dass dieselbe Datei, direkt vom USB-Stick gelesen, korrekt angezeigt wird! Und auch SysFileTree() liefert korrekte Informationen, und auch ffmpeg kann die Datei verarbeiten. Wie gesagt, der Stick ist mit Fat32 formatiert.

Eine Erklärung könnte lauten: Das JFS *war* mal ein modernes Filesystem, hat aber lange keine Updates mehr erhalten. Während der Fat32-Treiber auf der Höhe der Zeit ist. Oder lebe ich auf dem Mond und habe nicht mitgekriegt, dass es inzwischen eine neue Version vom JFS.IFS gibt? Ich nutze die vorinstallierte Version (vom 24.10.2016) aus dem ArcaOS 5.0.4.

Andererseits ist merkwürdig, dass VLC die Datei abspielen kann, von der JFS-Partition (woran, wie gesagt, ffmpeg scheitert).

Oder heißt das, dass meine Analyse, JFS sei schuld, unzutreffend ist?

Gruß,
Lutz W.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Das JFS *war* mal ein modernes Filesystem, hat aber lange keine Updates mehr erhalten. Während der Fat32-Treiber auf der Höhe der Zeit ist.
Umgekehrt. Unser JFS kann riesige Dateien, unser FAT32 aber nur 2GB (soweit ich weiß). Allerdings kann Win bei FAT32 auch bis zu 4GB -> Probleme vorprogrammiert. Also aufpassen, große Dateien unter OS/2 nur auf JFS.

AFAIR kann auch unser UDF nur 2GB, die aktuelle Win version aber ebenfalls 4GB.
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

Andi B. hat geschrieben: Fr 10. Feb 2023, 17:32
Das JFS *war* mal ein modernes Filesystem, hat aber lange keine Updates mehr erhalten. Während der Fat32-Treiber auf der Höhe der Zeit ist.
Umgekehrt. Unser JFS kann riesige Dateien, unser FAT32 aber nur 2GB (soweit ich weiß). Allerdings kann Win bei FAT32 auch bis zu 4GB -> Probleme vorprogrammiert. Also aufpassen, große Dateien unter OS/2 nur auf JFS.
Und wie erklärst du die Tatsache, dass meine 3,9 GB große Datei nicht verarbeitet werden kann, wenn sie auf meiner JFS-Partition liegt, aber sehr wohl verarbeitet wird, wenn sie auf dem USB-Stick (Fat32) liegt?
eCSBenutzer
Beiträge: 458
Registriert: Fr 10. Jan 2014, 07:24
Wohnort: 641m ü. NN

Beitrag von eCSBenutzer »

Und MP4 mit 3,9GB ist schon heftig, das müssen doch etliche Stunden sein.
Konnte denn ecs nicht auch NTFS zumindest lesen? Ich schleppe schon seit Generationen den Treiber in der Config.sys mit rum, aber wohl nur einmal benutzt. Liegt in /ECS/BOOT
Aber wie Andi schon bemerkte: JFS ist auf der Höhe der Zeit, nur die FAT-Geschichten sind (Hilfs-)Krücken.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

DonLucio hat geschrieben: Fr 10. Feb 2023, 18:18
Andi B. hat geschrieben: Fr 10. Feb 2023, 17:32
Das JFS *war* mal ein modernes Filesystem, hat aber lange keine Updates mehr erhalten. Während der Fat32-Treiber auf der Höhe der Zeit ist.
Umgekehrt. Unser JFS kann riesige Dateien, unser FAT32 aber nur 2GB (soweit ich weiß). Allerdings kann Win bei FAT32 auch bis zu 4GB -> Probleme vorprogrammiert. Also aufpassen, große Dateien unter OS/2 nur auf JFS.
Und wie erklärst du die Tatsache, dass meine 3,9 GB große Datei nicht verarbeitet werden kann, wenn sie auf meiner JFS-Partition liegt, aber sehr wohl verarbeitet wird, wenn sie auf dem USB-Stick (Fat32) liegt?
Gar nicht. Ich sag nur, FAT32, und vor allem unser Treiber, kann keine großen Dateien. JFS allerdings schon. Nicht mehr und nicht weniger. Ich glaube auch nicht, dass ffmpeg (irgendein portiertes Programm) Probleme mit >2GB Dateien hat. Aber in diesem Punkt muss ich zugeben, ich weiß es nicht. Alte OS/2 Programme haben jedoch schon des öfteren Probleme damit. Ich wundere mich aber schon, wie und warum du eine Datei auf FAT32 >2GB "verarbeiten" kannst.
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

Andi B. hat geschrieben: Fr 10. Feb 2023, 17:32 Ich wundere mich aber schon, wie und warum du eine Datei auf FAT32 >2GB "verarbeiten" kannst.
Da sind wir ja schon zu zweit. Fakt ist es aber:
SysFileTree("D:\MOV0001.MP4", "files.", "F") liefert Dateigröße=1 (D: -> JFS-formatiert)
SysFileTree("L:\MOV0001.MP4", "files.", "F") liefert Dateigröße=3,796,639k (L: -> Fat32-formatiert)
eCSBenutzer hat geschrieben:Und MP4 mit 3,9GB ist schon heftig, das müssen doch etliche Stunden sein.
VLC zeigt 15:26 mm:ss an und das stimmt auch. Die ungewöhnliche Dateigröße ist vielleicht damit zu erklären, dass mein Camcorder (Pearl-Billigmodell) mit ganz niedriger Kompression arbeitet, um eine ansehnliche Bildqualität hinzukriegen.

Aber das ist im Grunde für den vorliegenden Fall egal. Die Datei ist knapp unter 4 GB groß und läßt sich auf einer JFS-Partition nicht korrekt verarbeiten, auf einer Fat32-Partition schon (mit SysFileTree() und ffmpeg).

Die hier mehrfach geäußerte Meinung, JFS sei "top" und Fat32 "flop" deckt sich jedenfalls nicht mit meinen Erfahrungen. Vielleicht liegt die unerwartet gute Qualität meines Fat32-USB-Sticks an der Formatierung durch DFSee. Das Programm hat ja einen hervorragenden Ruf und der könnte sich hierdurch ein weiteres Mal bestätigt sehen. Bleibt nur die Frage: Wieso kann mein JFS die Dateigröße nicht korrekt anzeigen (jedenfalls nicht per SysFileTree()), mein Fat32 aber schon?

Ok, läßt sich wohl nicht klären. Ich werde mir jetzt für solche Fälle eine Fat32-Partition auf meiner Festplatte einrichten.

Danke einstweilen,
Lutz W.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

1) FAT32 ist immer noch ein 16-bit Dateisystemtreiber, unterstützt aber das neue Dateiattributformat (Infolevels) was auch Dateilängen grösser 2 GByte zurückmelden kann. Ich bin mir aber sicher, dass du weder in der gesamten Datei suchen kannst, noch dass auf die gesamte Dateilänge zugegriffen werden kann. Das hat zumindestens bei mir nicht mit Dumpdateien von > 3 GByte funktioniert (beim Zugriff mittels PMDF.EXE bzw. DF_RET.EXE).

2) Für den Zugriff auf Dateien > 2 GByte muss der Programmierer die neuen API Funktionen benutzen (wie z.B. DosSetFilePtrL statt DosSetFilePtr). Sonst kann man nämlich immer noch nicht auf Dateien > 2GByte zugreifen, auch wenn das Dateisystem auf dem sie liegen das kann.

3) vielleicht gibt es in der Tat einen Bug in JFS.IFS: SysFileTree scheint ja die neuen Funktionen zu nutzen, die Dateiattribute (Dateigrößen > 2GByte) richtig zurückmelden (siehe FAT32). JFS.IFS unterstützt die sicher auch, aber vielleicht hat sich da ein Bug eingeschlichen.

Ich habe ja dumpfs.inf als 32-bit IFS implementiert. Und auf meinem System werden Dumpdateien > 3GByte erzeugt, die ich auch auf meine JFS (Boot)Partition kopieren kann.
Ich kann jetzt mal ein REXX Skript mit "SysFileTree" Aufruf schreiben und vergleichen, was mein dumpfs.ifs auf seiner DUMPFS Partition als Dateilänge meldet und was JFS auf seiner Partition meldet.
Zuletzt geändert von erdmann am Sa 11. Feb 2023, 00:29, insgesamt 2-mal geändert.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Ok, hier der Testlauf:

auf der JFS Partition:
4/21/22 7:24a 1 ----- D:\DUMPDATA.001
4/22/22 2:03a 1 ----- D:\DUMPDATA.002
5/07/22 7:30a 1 ----- D:\DUMPDATA.003
5/22/22 5:51p 1 ----- D:\DUMPDATA.004
6/09/22 11:32a 1 ----- D:\DUMPDATA.005
8/25/22 8:20p 1 ----- D:\DUMPDATA.006
10/23/22 5:22p 1 ----- D:\dumpdata.007
1/01/23 3:35a 1 A---- D:\DUMPDATA.008

auf der DUMPFS Partition:
2/07/23 1:19a 3208708608 ---R- F:\DUMPDATA.001

Die Datei auf der DUMPFS Partition zeigt die richtige Länge (3208708608 Bytes). Die von mir auf die JFS Partition kopierten (und umbenannten) Dateien sollten genau die gleiche Länge haben. Und merkwürdigerweise wird die Dateilänge auch korrekt angezeigt wenn ich "dir dumpdata.*" auf einer Kommandozeile ausführe.

Also ja, JFS.IFS hat einen Bug beim Anzeigen von Dateilängen > 2 GByte. Aber merkwürdigerweise nur im Zusammenspiel mit "SysFileTree".

Oder auch nicht: Was ich sehen kann ist, dass der Aufruf von "SysFileTree" (entgegen meiner ursprünglichen Annahme) in einem Dateisystemaufruf von FS_FINDFIRST mit Infolevel FIL_STANDARD = 1 endet. Das liefert aber die Dateilänge in einem 32-bit Feld zurück.
Mein DUMPFS.IFS behandelt dieses Dateilängenfeld als "unsigned long", also können Dateilängen bis 2^32-1 Bytes = 4 GBytes - 1 Byte dargestellt werden. Ich nehme nun an, dass JFS.IFS dieses Dateilängenfeld als "signed long" behandelt und damit nur Dateilängen bis 2^31-1 Byes = 2 GBytes - 1 Byte zurückliefern kann. Und wahrscheinlich eine Prüfung enthält, dass wenn die Dateilänge das Maximum von 2 GBytes (-1) überschreitet, einfach "1 Byte" zurückliefert.

Genau aus diesem Grund wurden eben neue API Funktionen bzw. Infolevel (FIL_STANDARDL = 11) eingeführt (als "workaround") aber REXX ist so alt, dass es diese nicht nutzt. JFS.IFS hätte am besten einfach die vollen 32-bit als "unsigned long" benutzt. Aber natürlich würde auch das zu einem Fehler führen, wenn die Datei > 4 GByte - 1 Byte wäre. Da würde dann die Dateilängenangabe auf die untersten 32-bit geklippt.

Ich nehme nun an, dass FAT32.IFS sich so verhält wie mein DUMPFS.IFS (und das Dateilängenfeld als unsigned long behandelt und eben keine Längenprüfung macht).

Ich würde jetzt mal behaupten, dass ffmpeg unter FAT32 (oder schlimmer noch: weil es nur mit < 2 GByte Dateien umgehen kann) womöglich bei einer Länge von 2 GByte einfach an den Dateianfang "zurückwrapped". Ich wäre vorsichtig mit der Bearbeitung einer Datei >= 2 GByte auf einem FAT32 Laufwerk ...
Zuletzt geändert von erdmann am Sa 11. Feb 2023, 00:40, insgesamt 2-mal geändert.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Andi B. hat geschrieben: Fr 10. Feb 2023, 17:32 AFAIR kann auch unser UDF nur 2GB, die aktuelle Win version aber ebenfalls 4GB.
UDF.IFS ist als 32-bit IFS implementiert. Da würde ich schwer davon ausgehen, dass es auch mit Dateien >= 2 GByte umgehen kann. Sonst hätte man es nämlich auch als 16-bit IFS implementieren können.
Aber, wie schon erwähnt, OS/2 Programme müssen speziell für den Zugriff auf Dateien >= 2 GByte geschrieben werden. Ein großes Manko.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

UDF.IFS ist als 32-bit IFS implementiert. Da würde ich schwer davon ausgehen, dass es auch mit Dateien >= 2 GByte umgehen kann. Sonst hätte man es nämlich auch als 16-bit IFS implementieren können.
Ich meine in UDF2.0 (?), die Version die wir haben, war nur 2GB definiert, deshalb kann unser UDF nur <2GB. UDF2.1 (?) dann 4GB oder größer (keine Ahnung), aber 2.1 (?) haben wir nicht.

Kurz, wir OS/2 User haben Probleme mit >2GB Dateien auf z.B. DVD-RAM während Win (und auch z.B. der Panasonic VHS->DVD Recorder) durchaus 3,5GB große Dateien darauf packen.

Info - ich hab erst ca. 2010 in 4os2 LFS (LargeFileSupport) eingebaut. Es ist überhaupt nicht verwunderlich für mich, dass viele Teile, vor allem sowas uraltes wie unser REXX, keinen Schimmer davon haben, wie man mit >2GB Dateien umgehen kann. Sei froh, dass IBM wenigstens versucht hat das neue JFS so kompatibel zu machen wie möglich und das REXX bzw. andere uralte Programme nicht einfach trappen (the Microschrott way). Akzeptiere einfach, dass heutzutage FAT32 zu beschränkt ist (ebenso wie HPFS welches aber immerhin sehr flott ist) und lebe mit JFS. Ein besseres Filesystem wirst für OS/2 nie mehr kriegen.
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

erdmann hat geschrieben: Fr 10. Feb 2023, 23:27 2) Für den Zugriff auf Dateien > 2 GByte muss der Programmierer die neuen API Funktionen benutzen (wie z.B. DosSetFilePtrL statt DosSetFilePtr). Sonst kann man nämlich immer noch nicht auf Dateien > 2GByte zugreifen, auch wenn das Dateisystem auf dem sie liegen das kann.
Mag man ja auch nicht oft so gerne, extra fürs Anzeigen ein longlong zusammenzubasteln ;)

Ich versuch's mal methodisch zu trennen zwischen "Inhalt" und "Darstellung", dh. "File" und "FileInfo":
- JFS kann offensichtlich >2GB-Dateien speichern und zurückgeben. Beweis: "dir"-Command, bytegenau je nach %DIRCMD% .
- Insoweit dürfte auch IFS.JFS korrekt arbeiten - ("bugfree beweisen" lässt sich bekanntlich ja nie ...)
- Genau: Anwendungen, welche die Dateigröße korrekt darstellen oder gar Funktionen von abhängig machen, muss der Programmierer irgendwie anpassen.
Beispiele:
- SysFileTree() oder Stream(...'query size') schaffen das auch hier nicht; zum bloß größen-anzeigen mag man ja mit "cmd /c dir " tricksen...
- WPS Darstellung(!), Dateiobjekt->Eigenschaften->Datei: Vor allem wegen der 2GB hatte ich eWorkplace ersetzt durch jüngeres xWorkplace (light reichte dafür). Zu Zeiten der Ur-WPS waren sowieso höchstens 2GB-1 bekannt...
- zip/unzip: die neueren tun hier jedenfalls mit >2GB; ältere nicht, selbst wenn sie sich mit v.3.0/6.00 melden.
- Qt: hatte bei meiner zeitweisen Bastelei "no problem so far" ;)

Zum konkreten OP bin ich aber raus... :)
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

erdmann hat geschrieben: Sa 11. Feb 2023, 00:11 Ich würde jetzt mal behaupten, dass ffmpeg unter FAT32 ... womöglich bei einer Länge von 2 GByte einfach an den Dateianfang "zurückwrapped". Ich wäre vorsichtig mit der Bearbeitung einer Datei >= 2 GByte auf einem FAT32 Laufwerk ...
Das kann ich bestätigen! Ich hatte ja ursprünglich geschrieben, dass ffpmeg die Datei vom FAT32-Stick lesen kann. Aber es hat sich herausgestellt, dass er die Datei nicht in ihrer ganzen Länge lesen konnte.

Auf jeden Fall vielen Dank für deine ausführlichen Erklärungen, die mir zumindest helfen, das Problem besser zu verstehen.

Gruß,
Lutz W.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

LotharS hat geschrieben: Sa 11. Feb 2023, 10:17
erdmann hat geschrieben: Fr 10. Feb 2023, 23:27 2) Für den Zugriff auf Dateien > 2 GByte muss der Programmierer die neuen API Funktionen benutzen (wie z.B. DosSetFilePtrL statt DosSetFilePtr). Sonst kann man nämlich immer noch nicht auf Dateien > 2GByte zugreifen, auch wenn das Dateisystem auf dem sie liegen das kann.
Mag man ja auch nicht oft so gerne, extra fürs Anzeigen ein longlong zusammenzubasteln ;)

Ich versuch's mal methodisch zu trennen zwischen "Inhalt" und "Darstellung", dh. "File" und "FileInfo":
- JFS kann offensichtlich >2GB-Dateien speichern und zurückgeben. Beweis: "dir"-Command, bytegenau je nach %DIRCMD% .
- Insoweit dürfte auch IFS.JFS korrekt arbeiten - ("bugfree beweisen" lässt sich bekanntlich ja nie ...)
- Genau: Anwendungen, welche die Dateigröße korrekt darstellen oder gar Funktionen von abhängig machen, muss der Programmierer irgendwie anpassen.
Beispiele:
- SysFileTree() oder Stream(...'query size') schaffen das auch hier nicht; zum bloß größen-anzeigen mag man ja mit "cmd /c dir " tricksen...
- WPS Darstellung(!), Dateiobjekt->Eigenschaften->Datei: Vor allem wegen der 2GB hatte ich eWorkplace ersetzt durch jüngeres xWorkplace (light reichte dafür). Zu Zeiten der Ur-WPS waren sowieso höchstens 2GB-1 bekannt...
- zip/unzip: die neueren tun hier jedenfalls mit >2GB; ältere nicht, selbst wenn sie sich mit v.3.0/6.00 melden.
- Qt: hatte bei meiner zeitweisen Bastelei "no problem so far" ;)

Zum konkreten OP bin ich aber raus... :)
1) Ich glaube, dass die WPS (in den entsprechenden FileSystem Objektmethoden) mittlerweile die Dateigröße als double floating point Zahl führt. Dann braucht man auch keine LONGLONG (64-bit integer) Variable für die Anzeige. Ich bin mir aber nicht sicher. In jedem Fall muss aber natürlich die zugrundeliegende Dateisystem API Funktion erst mal einen 64-bit integer Wert liefern.

2) die WPS benutzt zur Abfrage der Dateilänge Gott sein Dank das Infolevel FIL_STANDARDL. Und das liefert ein signed long long (also signed 64-bit) Wert. Daraus kann man per floating point Umrechnung immer einen "gescheiten" floating point Wert berechnen (Ergebnis = 1.0 * 2^32 * HiDword + LowDword). Warum nun "signed long long" und nicht "unsigned long long" wo doch eine Dateilänge niemals negativ werden kann ? Weil oft mit einer signed long long Variable (z.B. einem negativen Dateioffset vom Dateiende) im IFS hin- und hergerechnet werden muss.

3) ob ein Programm in der Lage ist, mit >= 2 GByte Dateien umzugehen kann man ihm leider nicht ansehen (bzw. nur mit etwas Nachforschung bzgl. importierter API Funktionen herausfinden).

Das ganze Dateihandling in OS/2 ist designmäßig eine Katastrophe. Im Gegensatz zu Windows hat OS/2 eben nie alte Zöpfe abgeschnitten und hat an das Dateisystem neue Funktionalität "drangestrickt". Und die ist auch noch mies dokumentiert.
Antworten