Great program, very usefull for Rambooting compressed Wimboot VHDs by means of grub4dos 046a + SVBus driver
If I decompress (using -d parameter) a LZ4 compressed (using this parameters -12 --content-size --favor-decSpeed) Wimboot VHD even if I get a *.vhd file with exactly the same SHA1 Hash it can't be mounted on Windows.
But even if Windows is not able to mount the decompressed VHD it can be opened with 7-Zip as any other VHD file.
So far my findings are that if I check properties of the source VHD and the new decompresed VHD the size on disk is not the same.
It seems during decompression the VHD is not enterely rebuilded and unused space is not taken in consideration, another theory may be it remains in some kind of compressed state, then not using the full size on disk.
When the *.lz4 is loaded by grub4dos 0.46a it is decompressed and loaded to Ram and then Windows bootmanager is called to boot it, and all this process do not have any issue.
Also tested compressing and decompressing WinPE.iso(s) and all is working fine, even rebooted from decompressed WinPE.iso. The issue seems to be present only when decompressing LZ4 compressed VHDs.
Additional info and pictures on: http://reboot.pro/topic/22062-lz4-compressor/#entry211633
Thanks in advance for your time and effort.
It seems during decompression the VHD is not enterely rebuilded and unused space is not taken in consideration, another theory may be it remains in some kind of compressed state, then not using the full size on disk.
I'm not sure but it sounds it's caused by sparse file. If sparse mode causes the problem, you can disable sparse mode by the following command
lz4 --decompress --no-sparse <YOUR-FILE.lz4>
Thanks very much for your very fast answer, your suggestion worked very fine, no more troubles decompresind VHD.lz4 files.
You are doing a fantastic work here.
Most helpful comment
I'm not sure but it sounds it's caused by sparse file. If sparse mode causes the problem, you can disable sparse mode by the following command