-
Notifications
You must be signed in to change notification settings - Fork 499
Fix condition in rar v3 code #894
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix condition in rar v3 code #894
Conversation
adamhathcock
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems valid to me, not sure what to do to ensure this doesn't happen again. Tests or comments?
|
A test would be great but I don't know how to generate an archive that would exhibit this problem, I only used the archive provided in #890 to test this. I can add a comment to |
|
I'm imagining it has the same issue but I'm not an expert with it |
|
either this PR (or possible the OpenRead) PR has seemingly broke a disposing test on the reader? |
|
welp, it looks like applying this same diff on the rar5 code breaks it... not very reassuring. |
... yeah... apparently the thing that fixes rar3 code breaks rar5 code
This was an interesting one to track down. Basically, when
UnpWriteDatais called with a size of0, it must callwriteStream.Writeeven ifdestUnpSizeis 0 to ensure thatSuspendedis set to false.The same condition change must be done here:
sharpcompress/src/SharpCompress/Compressors/Rar/UnpackV1/Unpack.cs
Line 266 in 94789ce
to make sure that the code passes over both
if (destUnpSize < 0)andif (suspended)conditions and continues below.While investigating this bug I found some other issues in the rarVM code, but I'm not sure how to test them and whether that code is even still used nowadays.
TODO: Find some example archive that shows this bug that isn't 40MB and add a test case for it.