starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-07 05:34:35 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

Information about the corrupt file on multipart (rar) unpacking #274

New Issue
Open
opened 2026-01-29 22:09:24 +00:00 by claunia · 3 comments
claunia commented 2026-01-29 22:09:24 +00:00
Owner
Copy Link

Originally created by @SaculRennorb on GitHub (Jan 31, 2018).

Basically what it says on the tin,
would be really nice to send some information along with an InvalidFormatException that is thrown on unpacking a corrupt file, since you cant verify file integrity (yet... #246).
Something like a part / stream number would be enough already.

I had a look at the source already, but its not something i could easily implement.

My basic idea was to catch and re-throw the exception on the stream level to add the information, turns out to not be so simple tho, at least for me.

Originally created by @SaculRennorb on GitHub (Jan 31, 2018). Basically what it says on the tin, would be really nice to send some information along with an InvalidFormatException that is thrown on unpacking a corrupt file, since you cant verify file integrity (yet... #246). Something like a part / stream number would be enough already. I had a look at the source already, but its not something i could easily implement. My basic idea was to catch and re-throw the exception on the stream level to add the information, turns out to not be so simple tho, at least for me.
claunia commented 2026-01-29 22:09:25 +00:00
Author
Owner
Copy Link

@coderb commented on GitHub (Feb 1, 2018):

The info in #246 is old wrt rar. File integrity (crcs) are checked on both the entry headers and file data (which, I presume, is why you are encountering an InvalidFormatException).

If you want more information about which file is corrupt I'd recommend "testing" the archive in winrar.

The suggestion for more information on the exception is good though. Probably the decompression routines should be wrapping exceptions at the entry level and including additional information as to file part and entry location.

I'll take a look at adding this when I get back to working on the RAR5 branch if Adam hasn't already added it by then.

@coderb commented on GitHub (Feb 1, 2018): The info in #246 is old wrt rar. File integrity (crcs) are checked on both the entry headers and file data (which, I presume, is why you are encountering an InvalidFormatException). If you want more information about which file is corrupt I'd recommend "testing" the archive in winrar. The suggestion for more information on the exception is good though. Probably the decompression routines should be wrapping exceptions at the entry level and including additional information as to file part and entry location. I'll take a look at adding this when I get back to working on the RAR5 branch if Adam hasn't already added it by then.
claunia commented 2026-01-29 22:09:25 +00:00
Author
Owner
Copy Link

@SaculRennorb commented on GitHub (Feb 4, 2018):

Thing is, i'd use winrar but i kind of don't want to package a winrar distribution alongside sharpcompress. Im using this library in an automated process (who would have guessed) so i would like to be able to verify the files without any secondary program.

But since i cant use this lib to actively test for corruption I'd at least like to be able to tell someone which file is throwing the error.

@SaculRennorb commented on GitHub (Feb 4, 2018): Thing is, i'd use winrar but i kind of don't want to package a winrar distribution alongside sharpcompress. Im using this library in an automated process (who would have guessed) so i would like to be able to verify the files without any secondary program. But since i cant use this lib to actively test for corruption I'd at least like to be able to tell someone which file is throwing the error.
claunia commented 2026-01-29 22:09:26 +00:00
Author
Owner
Copy Link

@SaculRennorb commented on GitHub (Jul 29, 2018):

ok, so after halve a year i figured i look in the code some more and follow my original idea a bit deeper , and i came to the conclusion that changing the Read method of Compressors.Rar.RarCrcStream a bit would do the trick;

public override int Read(byte[] buffer, int offset, int count)
    {
        var result = base.Read(buffer, offset, count);
        if (result != 0) 
        {
            currentCrc = RarCRC.CheckCrc(currentCrc, buffer, offset, result);
        } 
        else if (GetCrc() != readStream.CurrentCrc && count != 0)
        {
            // NOTE: we use the last FileHeader in a multipart volume to check CRC
            var ex = new InvalidFormatException("file crc mismatch");
            
->        if (readStream is Compressors.Rar.MultiVolumeReadOnlyStream mvs) {
->           throw new Common.Exceptions.RarCorruptPartException(mvs.CurrentFileStreamName, ex);
->        }

            throw ex;
        }
        return result;
    }

where Common.Exceptions.RarCorruptPartException is just basically a normal System.Exception with a message and inner exception and mvs.CurrentFileStreamName is some private information i quickly exposed on Compressors.Rar.MultiVolumeReadOnlyStream as follows:

namespace SharpCompress.Compressors.Rar
{
  internal class MultiVolumeReadOnlyStream : Stream
  {
    [...]

    public string CurrentFileStreamName {
        get {
#if NETSTANDARD1_0
            return "Feature Not Available";
#else
            var s = (SharpCompress.IO.ReadOnlySubStream)currentStream;
            var ss = (SharpCompress.IO.NonDisposingStream)s.Stream;
            var sss = (System.IO.FileStream)ss.Stream;
            return sss.Name;
#endif
         }
     }

this seams to somewhat work, but only in part, as i always get the last stream, and never the 'current' one.

any ideas what i am doing wrong here are greatly appreciated

@SaculRennorb commented on GitHub (Jul 29, 2018): ok, so after halve a year i figured i look in the code some more and follow my original idea a bit deeper , and i came to the conclusion that changing the `Read` method of `Compressors.Rar.RarCrcStream` a bit would do the trick; public override int Read(byte[] buffer, int offset, int count) { var result = base.Read(buffer, offset, count); if (result != 0) { currentCrc = RarCRC.CheckCrc(currentCrc, buffer, offset, result); } else if (GetCrc() != readStream.CurrentCrc && count != 0) { // NOTE: we use the last FileHeader in a multipart volume to check CRC var ex = new InvalidFormatException("file crc mismatch"); -> if (readStream is Compressors.Rar.MultiVolumeReadOnlyStream mvs) { -> throw new Common.Exceptions.RarCorruptPartException(mvs.CurrentFileStreamName, ex); -> } throw ex; } return result; } where `Common.Exceptions.RarCorruptPartException` is just basically a normal `System.Exception` with a message and inner exception and `mvs.CurrentFileStreamName` is some private information i quickly exposed on `Compressors.Rar.MultiVolumeReadOnlyStream` as follows: namespace SharpCompress.Compressors.Rar { internal class MultiVolumeReadOnlyStream : Stream { [...] public string CurrentFileStreamName { get { #if NETSTANDARD1_0 return "Feature Not Available"; #else var s = (SharpCompress.IO.ReadOnlySubStream)currentStream; var ss = (SharpCompress.IO.NonDisposingStream)s.Stream; var sss = (System.IO.FileStream)ss.Stream; return sss.Name; #endif } } this seams to somewhat work, but only in part, as i always get the last stream, and never the 'current' one. any ideas what i am doing wrong here are greatly appreciated
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#274
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?