Vlákno názorů k článku Kompresní algoritmy v souborech ZIP: Store a Shrink od anonym - Neřekl bych, že je "store" algoritmus nezajímavý. Napadají...

Neřekl bych, že je "store" algoritmus nezajímavý. Napadají mě hned tři další využití. První je jednoduchá možnost šifrování, která je dostupná v převážné většině počítačů (doporučuji ale zjistit, jak kvalitně šifruje používaný program).
Druhé využití je zrychlení kopírování v případě, kdy jde o kopírování malých souborů. Záleži hodně na okolnostech, ale nějaká výhoda to je.
Třetí možnost jsem využil nedávno. Zálohoval jsem něco na externí disk a zjistil jsem, že 300 GB dat zabírá na disku 600 GB! (Malé soubory a velké clustery). Po velmi rychlém "store" zazipování jsem to setřepal na očekávaných 300GB

Algoritmus store je zajímavý také pro soubory, které už samy o sobě jsou komprimované – PNG, JPG, OOXML, ODF… Komprimovat je znovu je jen ztráta času, je jen věcí náhody, jestli se o pár bajtů zmenší nebo zvětší.

To zip nedělá, že by kontroloval kompresibilitu a podle toho měnil algoritmus. To musí udělat uživatel přepínačem -0, ale pak se to týká všech souborů. Ono je lepší asi pustit na všechno Deflate, již komprimované soubory se nijak podstatně nezvetší.

Tak jak říkáte tu kompresibilitu dopředu testuje například lrzip, k testování použije rychlý algoritmus lz4.

Malý test:

$ zip -r foo.zip *
....
adding: test/ugly/thre­enleof-vg.txt (deflated 45%)
adding: test/ugly/twobl-vg.txt (deflated 45%)
adding: test/ugly/twonleof-vg.txt (deflated 45%)
adding: test/ugly/hsclass-vg.txt (deflated 45%)
adding: test/.asm (stored 0%)
adding: test/test-int.out (deflated 73%)
adding: test/all.diff (stored 0%)
adding: test/selfcheck.out (stored 0%)

[jirka@omelette trunk]$ zip --version
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.

Výstup PKZIPu byl podobný (deflating, storing. imploding). Tak jsem něco asi špatně pochopil

No nevím, co jsou ty .asm, all.diff a selfcheck.out zač. Nemají velikost 0 třeba?

Teď jsem to tu zkoušel a deflate dělá u všeho včetně jpg, odt, pdf, kromě adresářů, nulových souborů a zip souborů, tam dělá store.

Ještě kompresibilitu testuje btrfs s parametrem compress=. Ale dělá to jen na kousku ze začátku souboru, takže pokud máte soubor na začátku náhodný a pak samé nuly, tak se nebude na disku komprimovat. Ono zase testovat celý soubor by trvalo dlouho.

Jde to obejít pomocí compress-force=, pak se nic netestuje a vše komprimuje.

Nedělá. On většinou ten deflate něco málo ubere, takže když jde člověk na hranu, tak to může dávat smysl. Pokud jde ale o soubory, které se pravidelně v runtime otvírají (například JAR), tak to procento ušetřené velikosti je dost kontraproduktivní, bo cena za opakovaně přetěžované CPU bude vyšší než ušetřených pár bytů.

Řešili jsme to někdy před dvaceti lety, když jsme vytvářeli zip se soubory pro hru - tehdy to byl snad jednoduchý shell nebo perl script, který pouštěl zip -0 nebo zip -9 podle přípony. Později jsem za jiným účelem napsal něco podobného znovu, s tím, že to rozlišovalo i úspěšnost komprese (byla to hračka na odpoledne, takže neumí příliš extra a má limity například kvůli byte array length, ale účel to splnilo, pull requests případně vítány ): https://github.com/kvr000/adaptive-zip

PS: zip dnes umí například i Zstandard, který je většinou lepší než Deflate, ale bude samozřejmě chvilku trvat, než jej budou všechny zip utility podporovat...

Nezajímavý pro popis, jinak uplatnění si najde. Stejně je možné použít tar a rychlou kompresi lzop, lz4, nebo zstd.