wimlib

Posted: **Mon Apr 03, 2023 4:39 am**

I have noticed that applying `wimoptimize --solid` to non-solid images (with the intention of converting a *.wim to *.esd, using non-precise terminology) produces different results compared to `wimexport all --solid`:

Code: Select all

$ cp install.wim install.wimoptimize.wim && wimoptimize install.wimoptimize.wim --solid
<...>

$ wi install.wimoptimize.wim
WIM Information:
----------------
Path:           install.wimoptimize.wim
GUID:           0xd5638fee51174b48a94cddf24232867e
Version:        3584
Image Count:    1
Compression:    LZX
Chunk Size:     32768 bytes
Part Number:    1/1
Boot Index:     0
Size:           2995830742 bytes
Attributes:     Relative path junction

Code: Select all

$ wimexport install.wim all install.wimexport.wim --solid
<...>

$ wi install.wimexport.wim
WIM Information:
----------------
Path:           install.wimexport.wim
GUID:           0x0aae24bc8504192232ef9b8b5214d604
Version:        3584
Image Count:    1
Compression:    LZMS
Chunk Size:     131072 bytes
Part Number:    1/1
Boot Index:     0
Size:           2995463376 bytes
Attributes:     Relative path junction

Note that the wimoptimized image (as reported by wiminfo) retains LZX compression type and the original chunk size..

===

Similar behavior happens in the opposite direction, making wimoptimize'd ESD->WIM images incompatible with Microsoft tooling (as they retain 128K chunk size even if you specify LZX compression):

Code: Select all

$ cp install.esd install.wimoptimize.wim && wimoptimize install.wimoptimize.wim --recompress --compress LZX:100
<...>

$ wi install.wimoptimize.wim
WIM Information:
----------------
Path:           install.wimoptimize.wim
GUID:           0x500206f59dc3fb87be2ad69c9881ece9
Version:        68864
Image Count:    1
Compression:    LZX
Chunk Size:     131072 bytes
Part Number:    1/1
Boot Index:     0
Size:           2348638435 bytes
Attributes:     Integrity info, Relative path junction

Posted: **Mon Apr 03, 2023 4:45 am**

As I can see, this is caused by

wimoptimize not resetting non-solid compression algorithm when --solid is passed, but --compress is not (unlike wimexport);
wimoptimize not resetting non-solid compression chunk size when the algorithm is changed (again, unlike wimexport).

I can pass both explicitly every time (which will result in a slightly unintuitive command line like `wimoptimize --solid --solid-compress=LZMS:100 --compress=LZMS:100 --chunk-size=128K` or opposite direction `wimoptimize --recompress --compress=LZX:100 --chunk-size=32K`), but maybe it is worth revisiting the CLI of wimoptimize command to make it a bit more consistent.

Posted: **Mon Apr 03, 2023 6:01 am**

Thanks, I agree that the defaults for wimoptimize should be improved. https://wimlib.net/git/?p=wimlib;a=comm ... cc27ccbf52 does this.

Posted: **Mon Apr 03, 2023 7:12 am**

Thank you for the quick response! I confirm that wimoptimize works as I'd expect it to work now.

Just one smallest thing, there's probably a typo in the new manpage example — the first command should probably say `wimoptimize install.esd ...`.

Posted: **Tue Apr 04, 2023 5:41 am**

Thanks, fixed now.

wimlib

wimoptimize vs. wimexport solid compression behavior

wimoptimize vs. wimexport solid compression behavior

Re: wimoptimize vs. wimexport solid compression behavior

Re: wimoptimize vs. wimexport solid compression behavior

Re: wimoptimize vs. wimexport solid compression behavior

Re: wimoptimize vs. wimexport solid compression behavior