[Solved] Default compressions' chunk sizes?

Comments, questions, bug reports, etc.
Post Reply
Hakkvild Yashnag-Slayer
Posts: 3
Joined: Sun Feb 17, 2019 1:59 pm

[Solved] Default compressions' chunk sizes?

Post by Hakkvild Yashnag-Slayer »

Hello,

if I optimize my WIM/ESD file using the --compress or the --solid-compress option but w/o specifying the --chunk-size option, will the compression chunk size be retained like it was set along with the previously selected compression format before the optimization command is executed or the new default chunk size for the target compression format will automatically replace it upon the optimization?

With that is going along the question what actually are default chunk sizes for individual compression formats? From the wimcapture(1) man page I could have only learnt about the LZMS one.

Thank You.
Last edited by Hakkvild Yashnag-Slayer on Tue Feb 19, 2019 11:56 am, edited 2 times in total.
synchronicity
Site Admin
Posts: 472
Joined: Sun Aug 02, 2015 10:31 pm

Re: Default compressions' chunk sizes?

Post by synchronicity »

The way it works now is that the non-solid chunk size stays the same as before, unless it's incompatible with the new --compress type in which case it's set to the default for the selected --compress type. The solid chunk size is different: it's always set to the default for the selected --solid-compress type. (The latter is somewhat of an artifact of the file format --- an archive may contain multiple solid resources with different compression types and/or chunk sizes, so there's not necessarily only a single existing solid compression format.)

The default chunk sizes are: 32K for XPRESS, 32K for LZX, 128K for LZMS non-solid or 64M for LZMS solid.
synchronicity
Site Admin
Posts: 472
Joined: Sun Aug 02, 2015 10:31 pm

Re: [Solved] Default compressions' chunk sizes?

Post by synchronicity »

Just a note for anyone who happens across this old thread:

wimlib v1.14.0 is planned to change 'wimoptimize' slightly to avoid some surprises when converting between solid and non-solid archives. The new behavior is that when 'wimoptimize' changes the WIM's non-solid compression type, the non-solid chunk size will be set back to the default (32K for XPRESS and LZX, 128K for LZMS) unless the --chunk-size option is given. This is in contrast to the previous behavior where e.g. 'wimoptimize --compress=LZX' on a WIM that used LZMS with 128K chunks would keep the chunk size at 128K.
Post Reply