[Linux] Welches Programm zippt mit Zstd?

[Krik]

Hallo zusammen,

unter KDE gib es den Dateimanager Dolphin. Bei dem kann man per Kontextmenü Dateien komprimieren:

[krik@krix ~]$ file leer.zip
leer.zip: Zip archive data, made by v6.3 UNIX, extract using at least v2.0, last modified, last modified Sun, Feb 12 2026 22:03:02, uncompressed size 0, method=Zstd

Und welches Programm hat er dafür im Hintergrund verwendet? Laut Internetsuche gibt es derzeit keine stabile Implementierung der Zstd-Methode bei Zip-Dateien. Für .7z und .tar.zstd gibt es das, aber hier wurde ja keine solche Datei erzeugt.
Weiß jemand, wie er das hinbekommen hat?

Gruß
Krik

 

[Alexander2]

was sagt unzip?

 

[Krik]

[krik@krix ~]$ unzip leer.zip
Archive:  leer.zip
   skipping: leer.txt                unsupported compression method 93

[krik@krix ~]$ unzip -v leer.zip
Archive:  leer.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
       0  Unk:093       9   0% 2026-02-12 22:17 00000000  leer.txt
--------          -------  ---                            -------
       0                9   0%                            1 file

 

[Alexander2]

Hm, und dolphin selber beschwert sich nicht? also dessen rechtsklick beim entpacken?

Sehe ich im endeffekt dann als Bug an, wenn ja beim zip standardarchiv umzip des nich kann.

 

[madmax2010]

https://github.com/KDE/ark/blob/master/plugins/libarchive/libarchiveplugin.cpp#L743
es nutzt libarchive

Und Libarchive nutzt im Backend wieder die Implementierung von Meta
https://github.com/facebook/zstd

 

[0x8100]

zip ist nur ein container und kann verschiedene algorithmen zum komprimieren verwenden, darunter auch zstd.

 

[Alexander2]

ich bevorzuge derzeit aber auch tar.lz4 mit lz4

ich mags schnell, ist aber sowas von schnell

Ergänzung (12. Februar 2026)

@0x8100 mag sein, aber aufgrund das es zip ist und wie und wo es alles eingesetzt wird. sollte man das wohl besser nicht machen. dann lieber sich daran halten was jeder 0815 unzipper kann oder gleich ein anderes Format, wo die Verwirrung nicht aufkommt.

 

[madmax2010]

wenn ja beim zip standardarchiv umzip des nich kann.

Unzip 6 ist aus 2009 https://infozip.sourceforge.net/UnZip.html#Release
Es hat seitdem keine patches fuer neue Standards bekommen. Ja, ich nutze es auch noch manchmal, ist halt leicht zu tippen und nicht tar mit 3-4 Parametern

Wie auch Ark in KDE, nutzt tar / bsdtar auch libarchive

Ergänzung (12. Februar 2026)

Archive: leer.zip Length Method Size Cmpr Date Time CRC-32 Name -------- ------ ------- ---- ---------- ----- -------- ---- 0 Unk:093

was du hier in Unknown: 093 siehst, ist die Codec Angabe im header, die sagt, dass zstd verwendet wurde
https://en.wikipedia.org/wiki/Zstd#:~:text=On 15 June 2020, Zstandard,7, released on 1 June.

 

[Alexander2]

Auf jeden fall irgendwas klappt da ja nicht, irgendwas ist nicht richtig?

 

[Krik]

Es klappt schon alles. Ich habe mich nur gefragt, wie das zustande kommt, wo doch keine der typischen Komprimierungsprogramme Zips mit Zstd erzeugen können.

bsdtar it is.

Das ist zwar nicht genau das, was Dolphin macht, kommt der Sache aber näher.

[krik@krix ~]$ bsdtar -c -f leer.zip --zstd leer.txt
[krik@krix ~]$ file leer.zip 
leer.zip: Zstandard compressed data (v0.8+), Dictionary ID: None

 

[foofoobar]

ich bevorzuge derzeit aber auch tar.lz4 mit lz4
Anhang anzeigen 1705686

ich mags schnell, ist aber sowas von schnell

Unterschätze zstd nicht:

$ for i in "lz4 -1" "lz4" "zstd -1" "zstd -4" ; do echo $i: ;time tar cf - x | $i | wc -c; done
lz4 -1:
417754964

real    0m2,795s
user    0m2,031s
sys    0m1,187s
lz4:
417754964

real    0m2,688s
user    0m1,938s
sys    0m1,149s
zstd -1:
257905694

real    0m1,980s
user    0m2,333s
sys    0m1,208s
zstd -4:
224704892

real    0m2,673s
user    0m3,038s
sys    0m1,275s

 

[Alexander2]

Ich würd den Vergleichswert doch irgendwo passender in Gbyt/s besser finden :-) denn wenn die SSD/RAM mitkommt ist das ja der bereich, wo sich das bewegt.


um mal einen nicht selbst gemachten Test, aber mit großen und Echten Daten zu Zeigen.

Achtung aufgrund der Datenquelle ist die Ausgangsgröße jeweils leicht anders, aber wenn man die Zeiten Sieht erübrigt sich das nitpicking total.

https://blog.stefan-betz.net/2016/11/12/borgbackup-lzma-zlib-und-lz4-im-vergleich/

also .. man könnte annehmen, das lz4 pi mal daumen so schnell gepackt hat wie der Datenreäger/Netzwerk was auch immer es schaffte Daten zu liefern.

Dein Beispiel mit nur 10 bytes oder so kaschiert leider die eigentliche komprimierung durch weitere vorgänge wie Datei anlegen etc..

 

[Piktogramm]

AMD Zen2 APU 6C/12T , Governor: powersave

 lz4 -b0 -e9
Benchmarking levels from 0 to 9
 0#Synthetic 50%     :  10000000 ->   5859357 (1.707),1364.9 MB/s ,7729.5 MB/s
 1#Synthetic 50%     :  10000000 ->   5859357 (1.707),1364.0 MB/s ,7740.0 MB/s
 2#Synthetic 50%     :  10000000 ->   5859357 (1.707),1364.5 MB/s ,7738.5 MB/s
 3#Synthetic 50%     :  10000000 ->   4560720 (2.193), 104.7 MB/s ,4878.8 MB/s
 4#Synthetic 50%     :  10000000 ->   4534386 (2.205),  83.8 MB/s ,4850.0 MB/s
 5#Synthetic 50%     :  10000000 ->   4529772 (2.208),  79.3 MB/s ,4841.6 MB/s
 6#Synthetic 50%     :  10000000 ->   4529581 (2.208),  76.1 MB/s ,4841.6 MB/s
 7#Synthetic 50%     :  10000000 ->   4529569 (2.208),  81.0 MB/s ,4841.7 MB/s
 8#Synthetic 50%     :  10000000 ->   4529565 (2.208),  80.9 MB/s ,4841.4 MB/s
 9#Synthetic 50%     :  10000000 ->   4529565 (2.208),  79.6 MB/s ,4841.3 MB/s

zstd -b0 -e9
 0#Synthetic 50%     :  10000000 ->   3230847 (x3.095),  243.2 MB/s, 1792.0 MB/s
 1#Synthetic 50%     :  10000000 ->   3154228 (x3.170),  500.3 MB/s, 2353.3 MB/s
 2#Synthetic 50%     :  10000000 ->   3129137 (x3.196),  419.2 MB/s, 2278.5 MB/s
 3#Synthetic 50%     :  10000000 ->   3230847 (x3.095),  242.7 MB/s, 1799.7 MB/s
 4#Synthetic 50%     :  10000000 ->   3345685 (x2.989),  150.6 MB/s, 1483.2 MB/s
 5#Synthetic 50%     :  10000000 ->   3292183 (x3.037),  102.1 MB/s, 1488.8 MB/s
 6#Synthetic 50%     :  10000000 ->   3280418 (x3.048),   91.7 MB/s, 1508.6 MB/s
 7#Synthetic 50%     :  10000000 ->   3327348 (x3.005),   69.3 MB/s, 1364.3 MB/s
 8#Synthetic 50%     :  10000000 ->   3318556 (x3.013),   63.0 MB/s, 1353.5 MB/s
 9#Synthetic 50%     :  10000000 ->   3355994 (x2.980),   48.3 MB/s, 1147.4 MB/s

Zstd im Benchmarkmodus mehr Threads zu spendieren bringt wenig, solang man sich nicht selbst einen etwas größeren Datensatz erzeugt hat. Der Synthetische Modus erzeugt irgend ein Lorem ipsum.

 

[Alexander2]

Ich verstehe die beiden MB/s Werte hintereinander pro Zeile nicht ganz, ein bischen Erklärung dazu wäre Hilfreich zum Verständnis, auch wenn ich sehe, das bei lz4 die deutlich größeren Werte auftauchen.

 

[foofoobar]

aber mit großen und Echten Daten zu Zeigen.

Was sind "unechte" Daten?

 

[Alexander2]

Ich habe die Daten vom Fileserver als Echte Daten bezeichnet, da es videodateien, Programmdateien etc sind. und sicher auch hier und da Textdateien. es ist zumindest näher an der üblich genutzten DAten dran als ein Datum also Text, mit nur ca 10 byte oder so das komprimiert werden soll.

Und du weißt das ganz genau was ich meine.
Statt eine Spitzfindigkeit aufzubringen frage ich lieber nach dem was ich als das eigentliche Problem sehe:
Würdest du mir tatsächlich widersprechen, das bei der geringen Datenmenge ganz andere Faktoren massiv überproportional mit reinspielen in der gebrauchten zeit und damit der Geschwindigkeit der Gesamtvorgänge?

 

[foofoobar]

Ich verstehe die beiden MB/s Werte hintereinander pro Zeile nicht ganz

https://man.archlinux.org/man/zstd.1.en#BENCHMARK

 

[Alexander2]

Ist bei dir schneller @Piktogramm

╰─$ lz4 -b0 -e9
Benchmarking levels from 0 to 9
 0#Lorem ipsum       :  10000000 ->   4690337 (2.132), 639.0 MB/s, 5779.8 MB/s
 1#Lorem ipsum       :  10000000 ->   4690337 (2.132), 638.1 MB/s, 5759.4 MB/s
 2#Lorem ipsum       :  10000000 ->   4227637 (2.365), 528.7 MB/s, 5315.3 MB/s
 3#Lorem ipsum       :  10000000 ->   3908374 (2.559), 151.5 MB/s, 5984.1 MB/s
 4#Lorem ipsum       :  10000000 ->   3751248 (2.666), 105.1 MB/s, 6242.4 MB/s
 5#Lorem ipsum       :  10000000 ->   3634435 (2.751),  73.0 MB/s, 6397.0 MB/s
 6#Lorem ipsum       :  10000000 ->   3552927 (2.815),  51.1 MB/s, 6499.8 MB/s
 7#Lorem ipsum       :  10000000 ->   3517813 (2.843),  39.3 MB/s, 6566.2 MB/s
 8#Lorem ipsum       :  10000000 ->   3508692 (2.850),  34.7 MB/s, 6555.3 MB/s
 9#Lorem ipsum       :  10000000 ->   3507509 (2.851),  34.0 MB/s, 6577.7 MB/s

Wobei, bei mir steht lorem ipsum, das scheint anders zu sein.
Und hat nur einen Kern genutzt.

 

[foofoobar]

Und du weißt das ganz genau was ich meine.

Nein.

Statt eine Spitzfindigkeit aufzubringen frage ich lieber nach dem was ich als das eigentliche Problem sehe:
Würdest du mir tatsächlich widersprechen, das bei der geringen Datenmenge ganz andere Faktoren massiv überproportional mit reinspielen in der gebrauchten zeit und damit der Geschwindigkeit der Gesamtvorgänge?

So besser?

$ for i in "lz4 -1" "lz4" "zstd -1" "zstd -4" ; do echo $i: ;time (for c in $(seq 1 6); do tar cf - x; done) | $i | wc -c; done
lz4 -1:
2506556847

real    0m16,206s
user    0m11,612s
sys    0m7,054s
lz4:
2506556847

real    0m16,163s
user    0m11,499s
sys    0m7,112s
zstd -1:
1547462904

real    0m11,885s
user    0m14,005s
sys    0m7,434s
zstd -4:
1347768468

real    0m16,335s
user    0m18,698s
sys    0m7,547s
$

 

[Donnerkind]

Ja, ich nutze es auch noch manchmal, ist halt leicht zu tippen und nicht tar mit 3-4 Parametern

Bei "unzip" sind die Buchstaben beim Tippen alle so eng beieinander auf der Tastatur, dass ich mit "tar xf" gefühlt schneller bin. 😁

Dein Beispiel mit nur 10 bytes oder so

es ist zumindest näher an der üblich genutzten DAten dran als ein Datum also Text, mit nur ca 10 byte oder so das komprimiert werden soll.

Woher nimmst du die 10 Bytes? foofoobars Einzeiler gibt die Größe der komprimierten Daten aus, die sich zwischen 224 MB (zstd -4) und 417 MB (lz4) bewegt.