mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-02-08 05:27:04 +00:00
[PR #118] Bugfix for inflate algorithm cutting of the end of certain blocks #849
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Original Pull Request: https://github.com/adamhathcock/sharpcompress/pull/118
State: closed
Merged: Yes
After tracking down a case of a corrupt file being extracted, I was able to isolate the issue to a single 100kb file. If I compress this file with the maximum compression, and decompress it, I the loose the trailing 109 bytes.
I have finally tracked down the issue and made this patch. The problem is that the number of bits requested is larger than the number of bits required. For the
LENandDISTcase, the number of required bitskis set tolbitsanddbitsrespectively. But if you look in the code below, you can see that they "consume" a variable number of bits, which in this case is less thank.For most cases this is not a problem, but when the last code to be processed hits this case, the decompression stops prematurely and this cuts of a number of bytes. Other zip implementations (unarchiver, 7zip, etc) handles this correctly. This bug is also present in jzlib and the DotNetZip libraries, but not in the SharpZipLib/ICSharp.ZipLib.
If have a file that can reproduce this, but I am awaiting clarification to see if I can provide publicly it.
As a side note, the inflater file contains some of the worst code I have seen. It is a mix of states stored in objects and scope, copied around. There are almost no comments, tens of single digit variables, and the control flow is ridiculously hard to follow. In many places the same code is simply copy-pasted rather than being encapsulated, which is why there are two changes to the source code. In other words: if you have another zip implementation, I suggest you go with that :).