You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While testing for #4, I noticed a bug in our handling of RAR5 solid files. Sometimes, we produce broken output.
Example:
1.txt blah
2.txt foo
rar -ma5 -s a test.rar 1.txt 2.txt
This creates a solid RAR5 file we can't correctly decompress. The first file extracts fine, the second doesn't. Seems to be connected to our "finishing off" of the remaining of the solid block. I assume it produces output that belongs into the second file instead of just influencing the state?
The text was updated successfully, but these errors were encountered:
As an update of sorts, I haven't yet found an easy way to fix this. It looks like I'll need to take apart solid file support and redo it mostly from scratch. I was basing it on partially wrong assumptions.
As a consequence, solid files are partially broken at the moment still. Partially meaning, it might work depending on the files that are bundled together in a solid chunk. Tiny files in particular are more prone to breaking. dmc_unrar isn't silently producing broken files, however, at least not as long as checksum validation is enabled.
While testing for #4, I noticed a bug in our handling of RAR5 solid files. Sometimes, we produce broken output.
Example:
1.txt
blah
2.txt
foo
rar -ma5 -s a test.rar 1.txt 2.txt
This creates a solid RAR5 file we can't correctly decompress. The first file extracts fine, the second doesn't. Seems to be connected to our "finishing off" of the remaining of the solid block. I assume it produces output that belongs into the second file instead of just influencing the state?
The text was updated successfully, but these errors were encountered: