eZip und *.7z

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

eZip und *.7z

Post by wilfried » Sun 21. May 2017, 19:30

Hallo,

ich bin im Besitz meiner ersten 7z-Datei (ArcaOS sei Dank). :D
Das ist der Anstoß für mich 7z in eZip einzubauen.
Oder hat das schon jemand erledigt?

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Sun 4. Jun 2017, 11:48

@Frank:

Ich habe eZip nun wieder auf einen vorzeigbaren Stand gebracht. Wie machen wir weiter?

User avatar
Frank Wochatz
Posts: 961
Joined: Sun 22. Dec 2013, 22:04
Location: Berlin

Post by Frank Wochatz » Mon 5. Jun 2017, 11:52

Hi Wilfried, lad deine Version ruhig mal hoch, ich komme zu nix...

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Mon 5. Jun 2017, 16:35

Ok here we are :D
ezip099g.zip
Getestet mit

ARJ/2-32 v 3.10g, Copyright (c) 1998-2003, ARJ Software Russia. [14 Sep 2003]

Lh2 (Compress files) (c)Peter Fitzsimmons 89/09/19
v2.28 03.10.24
Version 2.28 (32 bit wc)

7-Zip 9.13 beta Copyright (c) 1999-2010 Igor Pavlov 2010-04-15
p7zip Version 9.13 (locale=de_DE_EURO.IBM-850,Utf16=on,HugeFiles=on,2 CPUs)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

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

Post by ak120 » Thu 8. Jun 2017, 13:09

wilfried wrote:Ok here we are :D
ezip099g.zip

Getestet mit

ARJ/2-32 v 3.10g, Copyright (c) 1998-2003, ARJ Software Russia. [14 Sep 2003]

Lh2 (Compress files) (c)Peter Fitzsimmons 89/09/19
v2.28 03.10.24
Version 2.28 (32 bit wc)
Das verfrachten eines Ordners in ein LZH-Archiv funktioniert leider nicht. Eventuell unterstützt lh2 im Gegensatz zum originalen LHA für OS/2 keine Unterverzeichnisse?
7-Zip 9.13 beta Copyright (c) 1999-2010 Igor Pavlov 2010-04-15
p7zip Version 9.13 (locale=de_DE_EURO.IBM-850,Utf16=on,HugeFiles=on,2 CPUs)
Die Routine zur Berechnung der Komprimierungsrate ist sehr ungewöhnlich. Werte von über 100% sind zumindest mathematisch nicht nachvollziehbar.

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Thu 8. Jun 2017, 13:24

Vielen Dank für das Feedback!
Die Routine zur Berechnung der Komprimierungsrate ist sehr ungewöhnlich. Werte von über 100% sind zumindest mathematisch nicht nachvollziehbar.
Ein Beispiel wäre schön.
> 100% verstehe ich so, dass die komprimierte Datei größer ist als das Orginal. Z.B. eine ZIP-Datei in einer ZIP-Datei könnte das schaffen.
Lies: Die Datei konnte auf (nicht um) nn% verkleinert werden.

Das Verzeichnisthema mit LH2 schaue ich mir an.

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

Post by ak120 » Thu 8. Jun 2017, 15:47

wilfried wrote:Vielen Dank für das Feedback!
Die Routine zur Berechnung der Komprimierungsrate ist sehr ungewöhnlich. Werte von über 100% sind zumindest mathematisch nicht nachvollziehbar.
Ein Beispiel wäre schön.
Damit bezog ich mich eigentlich auf den Titel, also 7z. Ein beliebiges erzeugtes 7z-Archiv weist diese unsinnigen Werte im Informationsfenster auf. Zur Verdeutlichung ein Bild im Anhang. Zum Vergleich kann man ein zip-Archiv mit gleichem Inhalt heranziehen bei dem die Berechnung korrekt oder zumindest ziemlich genau ist.
ezip-7z.gif
> 100% verstehe ich so, dass die komprimierte Datei größer ist als das Orginal. Z.B. eine ZIP-Datei in einer ZIP-Datei könnte das schaffen.
Lies: Die Datei konnte auf (nicht um) nn% verkleinert werden.
In dem Fall müssten die Werte jedoch im negativen Bereich liegen.
Das Verzeichnisthema mit LH2 schaue ich mir an.
Das ist nur ein Aspekt. Wenn man lha.exe (in lh2.exe umbenannt) nutzt, funktioniert zumindest das Erstellen mehr schlecht als recht. Mit dem empfohlenen lh.exe (nach lh2.exe umbenannt) funktioniert hingegen fast nichts. Schon das Entpacken von http://www004.upp.so-net.ne.jp/hiramatu ... 2-2.08.lzh scheitert.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Thu 8. Jun 2017, 16:12

Ein Bild sagt mehr als 1000 Worte. ;)
Das sieht ganz nach einem Fehler aus. Ich schau es mir an.
Danke für den Hinweis.

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

Post by ak120 » Thu 8. Jun 2017, 17:27

wilfried wrote:Ein Bild sagt mehr als 1000 Worte. ;)
Das sieht ganz nach einem Fehler aus. Ich schau es mir an.
Nach Adam Ries sollten ungefähr 76,5 % herauskommen.
Die Größenangabe "compressed size" ist leider auch nicht genau, sondern gibt vielmehr die Größe der Archivdatei (in 7z-Terminologie "Physical Size" genannt) an. Dieser Wert unterscheidet sich von der Ausgabe von "7z -l" um die Kopfgröße ("Headers Size").

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

Post by LotharS » Thu 8. Jun 2017, 20:11

10032 - 2540 = 7492
? Die Ziffern kommen jedenfalls vor...

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Fri 9. Jun 2017, 10:07

zu LZH:

LHA OS/2 version Rel.2.08 Copyright (C) 1988-1996, Haruyasu Yoshizaki
Copyright (C) 1991-2000, Satoshi HIRAMATSU
=== <<< A High-Performance File-Compression Program >>> ====== May 07, 2000 ===

ist die bessere und aktuellere Impementierung.
Damit sollten dann auch Unterverzeichnisse funktionieren.
Da das Inhaltsverzeichnislayout vom bisher verwendeten LH2 abweicht, zeigt ezip damit aber nichts an.
Ich werde das anpassen.

zu 7Z:
Die Infoanzeige ist gefixt
Lies: Die Datei konnte auf (nicht um) nn% verkleinert werden.
Muss ich zurücknehmen. :(
Lies: Die Datei konnte um nn% verkleinert werden.

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Fri 9. Jun 2017, 20:01

Damit sollten dann auch Unterverzeichnisse funktionieren.
Aktuell geht mir das Wurzelverzeichnis verloren, d.h. dass Verzeichnis das auf dem eZip-Fenster fallen gelassen wird.
Die Struktur darunter kommt im LZH-Archiv an.
Zuletzt geändert von wilfried am Fri 9. Jun 2017, 20:50, insgesamt 1-mal geändert.

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

Post by ak120 » Sat 10. Jun 2017, 00:22

wilfried wrote:
Damit sollten dann auch Unterverzeichnisse funktionieren.
Aktuell geht mir das Wurzelverzeichnis verloren, d.h. dass Verzeichnis das auf dem eZip-Fenster fallen gelassen wird.
Die Struktur darunter kommt im LZH-Archiv an.
Ich weiß jetzt nicht welcher Aufruf intern genutzt oder oder aus der Prozedur heraus übergeben wird, aber hoffentlich wird stets der zusätzliche Schalter "-a" für die Dateiattribute verwendet.
Zuletzt geändert von ak120 am Sat 10. Jun 2017, 00:23, insgesamt 1-mal geändert.

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Sat 10. Jun 2017, 14:14

Aktuell geht mir das Wurzelverzeichnis verloren
Über diese Hürde bin ich drüber.

Habe aber ein neues Problem:
Wenn ich ein komplettes Verzeichnis ins LZH-Archiv zufüge, geht eine Datei mit folgendem Namen unter:
Jomic-Installer-0.9.34.jar
lh2 a -a -x -r empty.lzh INSTALL/
Als Einzeldatei kann ich sie zufügen. Haben wir hier einen Bug in LHA?
lh2 a -a -x -r empty.lzh INSTALL/Jomic-installer-0.9.34.jar
Das Zufügen habe ich direkt über Kommandozeile gemacht, weil D&D noch nicht läuft.
Das Navigieren durch das LZH-Archiv funktioniert aber inzwischen.

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

Post by ak120 » Sat 10. Jun 2017, 19:10

wilfried wrote:
Aktuell geht mir das Wurzelverzeichnis verloren
Über diese Hürde bin ich drüber.

Habe aber ein neues Problem:
Wenn ich ein komplettes Verzeichnis ins LZH-Archiv zufüge, geht eine Datei mit folgendem Namen unter:
Jomic-Installer-0.9.34.jar
lh2 a -a -x -r empty.lzh INSTALL/
Als Einzeldatei kann ich sie zufügen. Haben wir hier einen Bug in LHA?
Ich weiß jetzt zwar nicht, wozu der Schrägstrich da jetzt angehängt werden soll? Auf der Befehlszeile verwende ich üblicherweise einfach "lha a -read archiv INSTALL", wenn ich mich in dem Verzeichnis, welches den Ordner INSTALL enthält befinde. Habe es mit etlichen Dateien (auch mit dem von Dir angegebenen Namen) erprobt. Also "-d" wäre für Verzeichnisse schon angebracht, ".lzh" und angehängte "/" sind unnötig oder rufen nicht das gewünschte Verhalten hervor. Ob man -x auf einem deutschen System braucht, ist fraglich - mit der Option -reaxd wird es wohl keine Unterschiede geben.

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Sat 10. Jun 2017, 19:14

Also hier hat der '/' über das Wurzelverzeichnisproblem hinweg geholfen.
Mag sein das es bessere Lösungen gibt, aber das war die erste die ich gefunden habe. ;)
lh2 a -reaxd empty.lzh INSTALL
So geht es tatsächlich auch ohne '/'.
Danke fürs mittesten!
Zuletzt geändert von wilfried am Sat 10. Jun 2017, 19:21, insgesamt 1-mal geändert.

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Tue 13. Jun 2017, 14:28

zu LZH:
LHA OS/2 version Rel.2.08 Copyright (C) 1988-1996, Haruyasu Yoshizaki
Verhält sich nicht besonders freundlich zu OS/2. Beim Extrahieren entstehen Verzeichnisse auf die der Zugriff verweigert wird und die nach dem Löschen nicht mehr aus dem Papierkorb entfernt werden können, ausser man stellt die Verzeichnisse wieder her.
Später habe ich dann gemerkt das ich diese Unterverzeichnisse über die Kommandozeile loswerde.
Die WPS kann damit wohl nichts anfangen, weil der Objekttyp falsch gesetzt ist.

@all: Irgendwelche sachdienlichen Hinweise? ;)

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

Post by ak120 » Tue 13. Jun 2017, 19:45

wilfried wrote:Verhält sich nicht besonders freundlich zu OS/2.
Ich kann im Quelltext keine Verstöße feststellen, alles völlig normales und sauberes ANSI C unter Verwendung der Standardbibliothekten und der OS/2-API.
Beim Extrahieren entstehen Verzeichnisse auf die der Zugriff verweigert wird und die nach dem Löschen nicht mehr aus dem Papierkorb entfernt werden können, ausser man stellt die Verzeichnisse wieder her.
Ist die Umgebungsvariable DELDIR für die Verwendung des UNDELETE-Befehls ordnungsgemäß gesetzt. Davon kann man leider nicht bei jedem Zielsystem ausgehen. Wurde das Archiv auf dem gleichen Dateisystemtyp wiederhergestellt?

Ich gehe mal davon aus, daß mit Papierkorb eine Referenz auf das DELDIR-Verzeichnis gemeint ist.

Einen Schwachpunkt dieser LHA-Version möchte ich nicht verschweigen: Dies betrifft die englische Übersetzung der Benutzerschnittstelle und Meldungen. Wenn man nur diese zu Rate zieht und in seine Muttersprache übersetzt, kann die eigentliche Bedeutung gewisser Optionen schon mal komplett verloren gehen. Abhilfe schafft eine direkte Übersetzung aus dem japanischen ins deutsche, was dann wiederum eine Vielzahl automatischer Programme wie z.B. Google Translate ausschließt. Automatische Übersetzung mit Zwischenschritt in einer anderen höher entwickelten Sprache ist m.E. höchstens nur noch über Ungarisch sinnvoll.
Zuletzt geändert von ak120 am Tue 13. Jun 2017, 19:45, insgesamt 1-mal geändert.

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Tue 13. Jun 2017, 23:48

Ist die Umgebungsvariable DELDIR für die Verwendung des UNDELETE-Befehls ordnungsgemäß gesetzt. Davon kann man leider nicht bei jedem Zielsystem ausgehen. Wurde das Archiv auf dem gleichen Dateisystemtyp wiederhergestellt?

Ich gehe mal davon aus, daß mit Papierkorb eine Referenz auf das DELDIR-Verzeichnis gemeint ist.
Zur Klarstellung: Es geht um ein ECS 2.1 DE
der DELDIR-Eintrag befindet sich nicht in der CONFIG.SYS. Das Papierkorb-Objekt funktioniert ansonsten einwandfrei.
Ja das Ein- und Auspacken wird auf einem JFS-Laufwerk versucht.

zu LHA:
Ich habe im Netz folgendes Dokument gefunden und versuche damit meine offenen Fragen zu klären.
@node Main "LhA User's Guide"
Jan 2011

Written by Stefan Boberg
Currently Maintained by Sven Ottemann

Copyright (c) 1991-94 by Stefan Boberg
Copyright (c) 1998,1999 by Jim Cooper and David Tritscher
Copyright (c) 2004-2011 by Sven Ottemann

All rights reserved



Sven Ottemann <ac-logic@freenet.de>
@endnode

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Wed 14. Jun 2017, 12:20

Ich kann im Quelltext keine Verstöße feststellen, alles völlig normales und sauberes ANSI C unter Verwendung der Standardbibliothekten und der OS/2-API.
Ich habe auch mal einen Blick in den LHA-Source riskiert und finde FAT und HPFS namentlich erwähnt, allerdings kein Wort von JFS. Das könnte mein Problem sein!

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

Post by ak120 » Wed 14. Jun 2017, 14:57

wilfried wrote:Ich habe auch mal einen Blick in den LHA-Source riskiert und finde FAT und HPFS namentlich erwähnt, allerdings kein Wort von JFS. Das könnte mein Problem sein!
Selbst eine Vielzahl der in OS/2 mitgelieferten Programme haben keine explizite JFS-Unterstützung. Eine solche ist auch in den meisten Fällen überhaupt nicht erforderlich. Das soll jetzt nicht bedeuten, daß es keinen indirekten Zusammenhang gäbe.

Man kann natürlich jetzt unter FAT oder HPFS gegenprüfen, ob sich das Verhalten wirklich unterscheidet. Aber zuvor sollte man sicherstellen, daß alle beteiligten Prozesse die gleiche Zeichenumsetztabelle verwenden, insbesondere wenn diese miteinander kommunizieren.

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

Post by ak120 » Wed 14. Jun 2017, 15:30

wilfried wrote: Zur Klarstellung: Es geht um ein ECS 2.1 DE
der DELDIR-Eintrag befindet sich nicht in der CONFIG.SYS. Das Papierkorb-Objekt funktioniert ansonsten einwandfrei.
Dabei muß es sich wohl um ein Zusatzprogramm von einem Drittanbieter handeln. In der normalen OS/2-Dokumentation taucht nirgends ein Papierkorb-Objekt auf. Mir ist nur der Reißwolf (Klasse WPShredder) bekannt.
zu LHA:
Ich habe im Netz folgendes Dokument gefunden und versuche damit meine offenen Fragen zu klären.
Wer unbedingt unter OS/2 eine grafische Fensterdarstellung von LZH-Archiven oder sonstigen Archiv-Formaten benötigt, kann auch weiterhin PackMan Version 1.41 verwenden. Im Anhang findet sich eine angepaßte Profildatei, welche u.a. die Nutzung von 7z und Info-ZIP ermöglicht. Verzeichnisse in LZH, ZOO und ARC-Archiven sind ebenfalls möglich. Vielleicht hilft es ein wenig weiter.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Thu 15. Jun 2017, 00:18

Man kann natürlich jetzt unter FAT oder HPFS gegenprüfen, ob sich das Verhalten wirklich unterscheidet.
Habe das Temp-Verzeichnis auf eine HPFS-Partition verlegt. Die Verzeichnisse werden von LHA weiterhin falsch erzeugt.
Einzige Verbesserung: Extrahierte Dateien werden im Temp-Verzeichnis nicht mehr auf die 8.3 Namensgebung reduziert.

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

Post by ak120 » Thu 15. Jun 2017, 15:20

wilfried wrote:
Man kann natürlich jetzt unter FAT oder HPFS gegenprüfen, ob sich das Verhalten wirklich unterscheidet.
Habe das Temp-Verzeichnis auf eine HPFS-Partition verlegt. Die Verzeichnisse werden von LHA weiterhin falsch erzeugt.
Einzige Verbesserung: Extrahierte Dateien werden im Temp-Verzeichnis nicht mehr auf die 8.3 Namensgebung reduziert.
Wird mit der Unterstützung für die erweiterten Attribute entpackt? Da mir der Befehlsaufruf nicht bekannt ist, kann ich nur vermuten, daß die Archivdatei selbst die Ursache sein könnte.

User avatar
wilfried
Posts: 624
Joined: Mon 23. Dec 2013, 18:26
Location: Barsinghausen

Post by wilfried » Fri 16. Jun 2017, 00:45

@lh2.exe x -aempxr "L:\work_ezip\empty.LZH" "G:\temp\EZIP\20170616001409580000/" "INSTALL/BLUEJ/THIRDPARTYLICENSE.TXT"

Extracting from archive : L:/work_ezip/empty.LZH


Melting THIRDPAR.TXT .......
Melting THIRDPAR.TXT ooooooo
Melted
LHA OS/2 version Rel.2.08 Copyright (C) 1988-1996, Haruyasu Yoshizaki
Copyright (C) 1991-2000, Satoshi HIRAMATSU
=== <<< A High-Performance File-Compression Program >>> ====== May 07, 2000 ===
Usage: LHA [aufmdpexlvt] [-rwxmpcazthonils-dfey[-+012|WDIR]] LZH [DIR/] [FILES]
-------------------------------------------------------------------------------
<command> a: Add files u: Update files m: Move files
f: Freshen files d: Delete files p: disPlay files
e: Extract files x: eXtract files with pathnames
l: List of files v: View listing of files with pathnames
t: Test the integrity of archive
<option> r: Recursively collect files w: assign Work directory
x: allow eXtended file names m: no Message for query
p: distinguish full Path names c: skip time-stamp Check
a: allow any Attributes of files z: Zero compression (only store)
t: archive's Time-stamp option h: select Header level(default=1)
o: use Old compatible method n: display No indicator/pathname
i: not Ignore lower case l: display Long name with indicator
s: Skip by time is not reported -: '@' and/or '-' as usual letters
d: pack Directory name also f: Force to write without check
e: pack EA also y: allow anY filename of archives
===============================================================================
This LHA's reference is... hiramatu@ba2.so-net.ne.jp

[L:\WORK_EZIP][/font]
ezip1.jpg
ezip2.jpg
ezip3.jpg
ezip4.jpg
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.