You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BitFileExtractor extractor{ lib, BitFormat::SevenZip };
extractor.extract( "multi_volume.7z.001", "output/" );
Specify type: BitFormat: SevenZip to decompress normally
If we use BitFormat: Auto instead, it will generate intermediate files
Can BitFormat: Auto decompress normally? How to implement it?
BitArchiveReader arc{ lib, "multi_volume.7z.001", BitFormat::Auto};
Unable to read the contents of the multi volume compressed file correctly
BitFormat::SevenZip Is Right!!!
Do I have to read it twice here? Is it the first time to read the detection file format and then pass in the correctly detected BitFormat?
Can it be done all at once? Can BitFormat:: Auto read correctly at once? If so, how can it be implemented?
Usually, there are various formats of compressed files for user files, and it is very cumbersome to check the compression type for all of them
Looking forward to your reply very much!!!
The text was updated successfully, but these errors were encountered:
BitFileExtractor extractor{ lib, BitFormat::SevenZip };
extractor.extract( "multi_volume.7z.001", "output/" );
Specify type: BitFormat: SevenZip to decompress normally
If we use BitFormat: Auto instead, it will generate intermediate files
Can BitFormat: Auto decompress normally? How to implement it?
Unfortunately, no: when using BitFormat::Auto, bit7z first checks the extension of the archive, and if it doesn't find a known extension, it then checks the file signature.
In your case, the .001 extension is known and it is mapped to the BitFormat::Split format, so the first check is successful and makes bit7z merge the split files into the intermediate archive.
One possible fix would be to allow disabling the extension check and only check the signature, possibly at compile time. It would make bit7z detect the desired BitFormat::SevenZip format.
BitArchiveReader arc{ lib, "multi_volume.7z.001", BitFormat::Auto};
Unable to read the contents of the multi volume compressed file correctly
BitFormat::SevenZip Is Right!!!
The same applies here: using BitFormat::Auto is the same as BitFormat::Split due to the file extension check, so you should be able to read the metadata of the split archive (basically, it should show only one file, the intermediate 7z archive), but not the metadata inside the intermediate archive.
Do I have to read it twice here? Is it the first time to read the detection file format and then pass in the correctly detected BitFormat?
Can it be done all at once? Can BitFormat:: Auto read correctly at once? If so, how can it be implemented?
Usually, there are various formats of compressed files for user files, and it is very cumbersome to check the compression type for all of them
Looking forward to your reply very much!!!
Unfortunately, the only workaround at the moment is to check if bit7z can open the archive using specific formats rather than using BitFormat::Auto.
I'll work on implementing the signature-only format check for the next version of the library.
BitFileExtractor extractor{ lib, BitFormat::SevenZip };
extractor.extract( "multi_volume.7z.001", "output/" );
Specify type: BitFormat: SevenZip to decompress normally
If we use BitFormat: Auto instead, it will generate intermediate files
Can BitFormat: Auto decompress normally? How to implement it?
BitArchiveReader arc{ lib, "multi_volume.7z.001", BitFormat::Auto};
Unable to read the contents of the multi volume compressed file correctly
BitFormat::SevenZip Is Right!!!
Do I have to read it twice here? Is it the first time to read the detection file format and then pass in the correctly detected BitFormat?
Can it be done all at once? Can BitFormat:: Auto read correctly at once? If so, how can it be implemented?
Usually, there are various formats of compressed files for user files, and it is very cumbersome to check the compression type for all of them
Looking forward to your reply very much!!!
The text was updated successfully, but these errors were encountered: