[Feature Request]: Suggestions for Decompressing Callback Logic

[psvajaz]

Feature description

During the decompression process, the situation: when the setFileCallback is triggered during the decompression process, only the file name (without directory information) is provided and no callback is made when decompressing the directory. The return value of the Callback is only whether the current file needs to be decompressed.
Suggestion: When triggering the setFileCallback setting function during the decompression process, the item of the directory and the file should be used as the Callback parameter. In this way, the developer can display more comprehensive information to the user, allowing the user to choose how to operate; in the return of the Callback function In addition to whether to decompress the current file, the value should also provide the decompression path, so that the developer has more room for manipulation when the user chooses to overwrite or rename

Additional context

No response

Code of Conduct

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

[rikyoz]

only the file name (without directory information) is provided

Not since the v4.0.0-rc, where the callback provides the full path of the file within the archive, not just its file name.

and no callback is made when decompressing the directory

The problem is that directories are not actually "extracted"; when bit7z encounters a directory item, it simply recreates it in the output folder.

When triggering the setFileCallback setting function during the decompression process, the item of the directory and the file should be used as the Callback parameter. In this way, the developer can display more comprehensive information to the user, allowing the user to choose how to operate

I'm evaluating whether to provide a const BitArchiveItem& parameter for the file callback.
This would give the user more information about the file being extracted.
But this would be a breaking change, so I'll evaluate it for a follow-up version (not for v4.0).

Another option would be adding a new "item" callback, which should also report directories.
But this would add some overhead to all the library's users.

in the return of the Callback function In addition to whether to decompress the current file, the value should also provide the decompression path, so that the developer has more room for manipulation when the user chooses to overwrite or rename

Returning the decompression path would make the API less easy to use for users not interested in manipulating such information.
But being able to overwrite or rename the extracted file is indeed helpful. I'll evaluate what's the best approach to support it.

Thanks for the suggestions!