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.
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

eZip und *.7z

Beitragvon wilfried » So 21. Mai 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?
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » So 4. Jun 2017, 11:48

@Frank:

Ich habe eZip nun wieder auf einen vorzeigbaren Stand gebracht. Wie machen wir weiter?
Benutzeravatar
Frank Wochatz
Beiträge: 783
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitragvon Frank Wochatz » Mo 5. Jun 2017, 11:52

Hi Wilfried, lad deine Version ruhig mal hoch, ich komme zu nix...
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Mo 5. Jun 2017, 16:35

Ok here we are :D
ezip099g.zip
Erweitert um Support für ARJ, LZH und 7Z
(654.29 KiB) 46-mal heruntergeladen


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)
Benutzeravatar
ak120
Beiträge: 738
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Do 8. Jun 2017, 13:09

wilfried hat geschrieben: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.
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Do 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.
Benutzeravatar
ak120
Beiträge: 738
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Do 8. Jun 2017, 15:47

wilfried hat geschrieben: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
ezip-7z.gif (3.17 KiB) 2066 mal betrachtet


> 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/OS2/lha/lha2-2.08.lzh scheitert.
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Do 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.
Benutzeravatar
ak120
Beiträge: 738
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Do 8. Jun 2017, 17:27

wilfried hat geschrieben: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").
Benutzeravatar
LotharS
Beiträge: 424
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitragvon LotharS » Do 8. Jun 2017, 20:11

10032 - 2540 = 7492
? Die Ziffern kommen jedenfalls vor...
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Fr 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.
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Fr 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 Fr 9. Jun 2017, 20:50, insgesamt 1-mal geändert.
Benutzeravatar
ak120
Beiträge: 738
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Sa 10. Jun 2017, 00:22

wilfried hat geschrieben:
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 Sa 10. Jun 2017, 00:23, insgesamt 1-mal geändert.
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Sa 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.
Benutzeravatar
ak120
Beiträge: 738
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Sa 10. Jun 2017, 19:10

wilfried hat geschrieben:
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.
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Sa 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 Sa 10. Jun 2017, 19:21, insgesamt 1-mal geändert.
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Di 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? ;)
Benutzeravatar
ak120
Beiträge: 738
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Di 13. Jun 2017, 19:45

wilfried hat geschrieben: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 Di 13. Jun 2017, 19:45, insgesamt 1-mal geändert.
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Di 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
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Mi 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!
Benutzeravatar
ak120
Beiträge: 738
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Mi 14. Jun 2017, 14:57

wilfried hat geschrieben: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.
Benutzeravatar
ak120
Beiträge: 738
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Mi 14. Jun 2017, 15:30

wilfried hat geschrieben: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.
Dateianhänge
packman.gif
packman.gif (10.26 KiB) 1634 mal betrachtet
packman-7z.zip
(770 Bytes) 20-mal heruntergeladen
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Do 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.
Benutzeravatar
ak120
Beiträge: 738
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Do 15. Jun 2017, 15:20

wilfried hat geschrieben:
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.
Benutzeravatar
wilfried
Beiträge: 538
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitragvon wilfried » Fr 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
Der Ordner mit dem obskuren Unterverzeichnis

ezip2.jpg
Die Objektklasse

ezip3.jpg
Der Beweis das es ein Unterverzeichnis ist

ezip4.jpg
Der Doppelklick auf das Verzeichnis liefert ...
ezip4.jpg (8.66 KiB) 1517 mal betrachtet

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast