Skip to content

Correct mszip extraction on some cabs currently relies on an exception being thrown #44

@HeroponRikiBestest

Description

@HeroponRikiBestest

To preface; technically, there's no issue with mszip extraction (that I know of) right now; what I describe results in the proper file data being extracted.

At the moment, on some mszip cabs, extraction will hit the following:

Console.Error.WriteLine($"Data block {blockIndex} in folder {folderIndex} had mismatching sizes. Expected: {block.UncompressedSize}, Got: {stream.Length}");

The program will pad the block out to 32768 bytes, and write it to the stream.
Every time this happens, the immediate subsequent block will throw an exception on this line:

Resulting in log output looking like this:

Data block 27168 in folder 0 had mismatching sizes. Expected: 32768, Got: 13139
System.IO.InvalidDataException: source
   at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug)
System.IO.InvalidDataException: source
   at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug)
Data block 10321 in folder 0 had mismatching sizes. Expected: 32768, Got: 13139
System.IO.InvalidDataException: source
   at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug)
Data block 16068 in folder 0 had mismatching sizes. Expected: 32768, Got: 16904
System.IO.InvalidDataException: source
   at SabreTools.Serialization.Wrappers.MicrosoftCabinet.DecompressMSZIPBlock(Int32 folderIndex, Decompressor mszip, Int32 blockIndex, CFDATA block, Byte[] blockData, Boolean includeDebug)

However, this doesn't actually seem to cause any issues. The resulting files that are extracted have all the right data, and match 1:1 against extraction from other programs like 7z.

Despite this, I'm opening an issue since it seems potentially dangerous to rely on an exception being thrown for proper output, especially if any other changes are made to this section. It also makes it more difficult to find actual issues in the console output.

This happens on some number of mszip cabs, but not all of them. The cab used in this issue was the 27-part cab inside 2K Sports Major League Baseball 2K9 (USA).iso http://redump.org/disc/59967/ , where this occurs several times.

Other examples include the multi-part cab inside Singularity (Europe) (En,Fr,Es,It).iso http://redump.org/disc/52122/ , inside Lost Planet - Extreme Condition - Colonies Edition (Russia) (En,Ja,Fr,De,Es,It,Ko,Pl,Ru) (Disc 1) http://redump.org/disc/80571/ , and inside Brothers in Arms - Hell's Highway (Germany) (En,De) http://redump.org/disc/85478/ . More examples can be provided if necessary.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions