mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-02-05 21:23:57 +00:00
RarArchive Entry Stream not Copying correctly #476
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?
Originally created by @CBeatt13 on GitHub (Sep 26, 2021).
Having an issue extracting a RAR archive entry to another stream. If I extract the whole archive the files extract correctly. If I attempt to extract a single entry to either a file or I open the entry stream and then copy that to another stream the file is corrupted. The file I'm extracting is a JPG image, when I attempt to extract the single image the image renders the top 20 lines or so of pixels then the rest of the image is all saved as grey. This only seems to happen sporadically but does happen pretty often for me.
@CBeatt13 commented on GitHub (Sep 26, 2021):
Adding some more potentially useful information:
Version to extract on the archive in question is 2.0 (According to WinRAR)
SharpCompress reads that the entry in question is complete
Archive isn't password protected at all
Have the issue both when reading the first entity immediately, as well as right after using a LINQ statement on all entries to re-order (which I assume is reading all the entities)
@adamhathcock commented on GitHub (Sep 27, 2021):
Without seeing any code, it sounds similar to this problem: https://github.com/adamhathcock/sharpcompress/issues/620
@CBeatt13 commented on GitHub (Sep 27, 2021):
I'll get ya a code snippet to show what I'm referring to. Main differences between this and #620 are the following:
I have the issue exclusively with RAR archives
The issue doesn't happen for ALL archives
I don't have to iterate or manipulate the Entry enumerable to see the issue in question
I'm not attempting to iterate the archive's entry enumerable after navigating to the first entry
@CBeatt13 commented on GitHub (Sep 27, 2021):
Code I'm using that generates the issue, it's worth noting I can make it happen still after removing the LINQ query:
@CBeatt13 commented on GitHub (Sep 27, 2021):
Later tonight if you don't have an idea what may be causing the issue I'll pull down the code and see if I can help track down the cause
@CBeatt13 commented on GitHub (Sep 27, 2021):
Just used the same file in your ComicBlaze project (since it's basically doing the same thing) and the issue exists there as well for the file in question
@adamhathcock commented on GitHub (Sep 27, 2021):
If you do
ToList()on the foreach, does it still happen?@CBeatt13 commented on GitHub (Sep 27, 2021):
No change when adding .ToList(). Also still does it if I remove the ForEach entirely and just call archive.Entries.First then run the logic accordingly.
@CBeatt13 commented on GitHub (Sep 28, 2021):
Minimum code required to get this issue is below. File is a CBR with copyright material in it so can't directly attach it to the ticket, but can get it to ya if you need.
@CBeatt13 commented on GitHub (Sep 28, 2021):
Tried to step through but there is enough work being done moving stuff back and forth between streams and buffers that I'm not even sure where to begin pin-pointing what could be the culprit. If there is anything more you need me to try and test though let me know and I'll do my best with it.
@CBeatt13 commented on GitHub (Sep 30, 2021):
Been looking more into this and it only appears to be an issue with a version 2.0 RAR archive, and only when extracting individual entries, extracting the entire archive works as expected.
@adamhathcock commented on GitHub (Oct 1, 2021):
A RAR 2.0 file is something that's pretty old now, isn't it? I'm just wondering how to narrow this down
@CBeatt13 commented on GitHub (Oct 1, 2021):
The codebase has a switch in that it uses to perform stream copy operations based on the RAR format and 2.0 has it's own case in that switch, so would imagine that'd be a good start. Compare that logic to the logic used to extract the entire archive since that IS working. I'd imagine there is a unintended difference in the two parts of code. At work right now so can't get you the exact file/line number of the switch I'm referring to, but can tonight once home.
@nausixkiz commented on GitHub (Dec 23, 2021):
Same issue
@adamhathcock commented on GitHub (Dec 24, 2021):
Creating a test with a matching file would probably help here. If a broken test was in a PR, then me or someone else could fix it.
@Nanook commented on GitHub (Feb 15, 2022):
https://github.com/adamhathcock/sharpcompress/pull/638
I hope this solves this issue.
@adamhathcock commented on GitHub (Mar 30, 2022):
Fix released in https://www.nuget.org/packages/SharpCompress/0.31.0