[Bug]: BitArchiveReader.volumesCount() is wrong for ".7z.001" and ".zip.001"

[josefschroettle]

bit7z version

4.0.x

Compilation options

BIT7Z_AUTO_FORMAT

7-zip version

v23.01

7-zip shared library used

7z.dll / 7z.so

Compilers

MSVC

Compiler versions

MSVC 2022

Architecture

x86_64

Operating system

Windows

Operating system versions

Windows 11

Bug description

When BitArchiveReader is created with a file "test.7z.001" with the correct format BitFormat::SevenZip (because Auto is not working) the archive opens and can be listed and extracted which is good.
But BitArchiveReader.volumesCount() returns 1 instead of the correct count 3 in my case which forces me into a workaround to count the files on my own for deletion after unpacking.

Steps to reproduce

Create spanned archive in 7z which will result in ".7z.001", ".7z.002", etc.
Open in BitArchiveReader(lib, ".7z.001", BitFormat::SevenZip)
Call volumesCount()

Expected behavior

volumesCount() returns > 1

Relevant compilation output

volumesCount() == 1

Code of Conduct

• By submitting this issue, I agree to follow bit7z's Code of Conduct

[rikyoz]

Hi!

because Auto is not working

The automatic format detection works by first checking the extension of the archive file, which in this case is .001. This is the extension of the BitFormat::Split format, not BitFormat::SevenZip, so bit7z will open the archive using this format.
This format basically allows you to read/recreate the whole .7z archive from the splitted/volume files, not to read inside the whole .7z itself.
So BitFormat::Auto does work, but not as expected.

In the next v4.0.10 (which I hope to release as soon as possible), I have already implemented a workaround: building bit7z with the option -DBIT7Z_DETECT_FROM_EXTENSION=OFF will disable the format detection from the file extension, forcing the library to only check the file signature.
This will cause bit7z to detect BitFormat::SevenZip in the case of .7z.001 files, as you needed.

But BitArchiveReader.volumesCount() returns 1 instead of the correct count 3 in my case which forces me into a workaround to count the files on my own for deletion after unpacking.

The volumesCount() method simply checks the archive's BitProperty::NumVolumes property, which 7-Zip doesn't report, because technically 7z archives do not support multiple volumes, and thus bit7z reports 1.
7-Zip uses the Split format to achieve multiple volumes.

I'm thinking of adding an additional physicalVolumesCount() which would basically work like your workaround and count the actual files.
Or just change the behavior of volumesCount() when 7-Zip doesn't return a value for NumVolumes and implement the workaround there.
I still need to find out which is the best approach, but at the moment I'm leaning towards the first one.

[josefschroettle]

So I really look forward to version v4.0.10 :-)
Another reason to choose format 'Auto' was that it selects 'Rar' or 'Rar5' automatically which I cannot deduce from the suffix ".rar". And if I specify 'Rar' then bit7z cannot open archives in 'Rar5' format. (I have not tried to open older Rar formats with 'Rar5' yet)
To your last question I would recommend to change the behavior of 'volumesCount()'. This keeps the interface small and consistent. When you would add the function 'physicalVolumesCount()', the user of your library would have to decide which function to use. When 'volumesCount()' returns 1 the user would have to look at the suffix (for ".001") and then call 'physicalVolumesCount()', not nice.
Thank you for your support and keep up the good work!

[rikyoz]

So I really look forward to version v4.0.10 :-)

Just released! :)

To your last question I would recommend to change the behavior of 'volumesCount()'. This keeps the interface small and consistent. When you would add the function 'physicalVolumesCount()', the user of your library would have to decide which function to use. When 'volumesCount()' returns 1 the user would have to look at the suffix (for ".001") and then call 'physicalVolumesCount()', not nice.

In the end, I decided to modify the volumesCount() method as you suggested.
It was the cleanest choice and made the behaviour of the method what everyone expects it to be.

Thank you for your support and keep up the good work!

You're welcome, and thank you for using the library and giving me feedback!