rikyoz / bit7z

A C++ static library offering a clean and simple interface to the 7-zip shared libraries.
https://rikyoz.github.io/bit7z
Mozilla Public License 2.0
634 stars 116 forks source link

[Bug]: split 7z files and bit7z::BitFormat::Auto #127

Closed RScherzer closed 1 year ago

RScherzer commented 1 year ago

bit7z version

4.0.x RC

Compilation options

BIT7Z_AUTO_FORMAT, BIT7Z_USE_NATIVE_STRING

7-zip version

v22.01

7-zip shared library used

7z.dll / 7z.so

Compilers

MSVC

Compiler versions

MSV2022

Architecture

x86_64

Operating system

Windows

Operating system versions

Windows 11

Bug description

Using a compiled version with BIT7Z_AUTO_FORMAT.

Trying to open a split 7z archive with several files with bit7z::BitFormat::Auto mode. This results in a problem:

archive.detectedFormat() returns bit7z::BitFormat::Split which seems to be plausible, however archive.items() holds exactly 1 item entry with not good looking mItemProperties.

When I use bit7z::BitFormat::SevenZip to open the file, it works fine, items() returns all entries with valid size/checksum etc values.

So, there might be something wrong with bit7z::BitFormat::Split detected formats or I may need to use a different approach?

...and by the way: shouldn't archive.isMultiVolume() return true in since it return always false. Split RAR files is fine, there it detects it right and isMultiVolume also returns true;

Steps to reproduce

No response

Expected behavior

No response

Relevant compilation output

No response

Code of Conduct

rikyoz commented 1 year ago

Hi!

archive.detectedFormat() returns bit7z::BitFormat::Split which seems to be plausible, however archive.items() holds exactly 1 item entry with not good looking mItemProperties.

This is the expected behavior when the archive format is BitFormat::Split. 7-zip treats split archives as an archive containing only one item: the whole archive. In fact, if you extract a multi-volume archive using the Split format, you should obtain the full archive.

When I use bit7z::BitFormat::SevenZip to open the file, it works fine, items() returns all entries with valid size/checksum etc values.

This is a recent addition to the library: before the release candidate, you had first to extract the split archive to recreate the whole one on the disk, and then you had to extract this latter.

So, there might be something wrong with bit7z::BitFormat::Split detected formats or I may need to use a different approach?

The recent change in the release candidate is also why the detected format is still BitFormat::Split: before, it was the only format that could handle multi-volume archives (with the exception of RAR ones, which have a different extension though).

However, I'm considering changing the detection behavior since now bit7z can extract multi-volume archives without creating the whole intermediate archive.

...and by the way: shouldn't archive.isMultiVolume() return true in since it return always false. Split RAR files is fine, there it detects it right and isMultiVolume also returns true;

isMultiVolume() queries the IsVolume property as reported by 7-zip. It should return true for Split and multi-volume RARs, as you said.

However, when opening a multi-volume directly using the SevenZip format, it essentially treats it as a whole 7z archive; this might be the reason for the different result. I'll need to check if it's possible to make the function return true in this case.

RScherzer commented 1 year ago

ah...ok..makes sense, thanks for your support!

rikyoz commented 1 year ago

No problem, happy to have helped!