Description
This case was originally proposed in the discussion of #2723.
There are a number of cases where extractcode fails to fully recursively unpack an archive. Embedded in the archive can be corrupt compressed content, or perhaps there are files that are recognized as archives, but an unarchiver is not configured for the current system. In these cases, extractcode partially succeeds and partially fails. (It unarchives some content but there is at least one recognized archive file seen in the recursion that it cannot unpack.)
In these cases, it would be helpful for the system using extractcode to know the difference between extractcode "utter failure" such as command line error or unable to do any work on the passed archive, and a partial unpack, where some elements are extracted but there is at least one failure along the way. The suggestion here is to use a different return code for this case.
Right now, extractcode returns "0" on success and "1" on failure. This issue proposes that extractcode keep track of any interim unpack failures, and use the return code of "2" if some unpacking is done, but at least one recursive unpack failed.
How To Reproduce
A current test case is that provided in #2723, repeated here:
The target archive is here. Within the Ruby Rake zipfile is what appears to be a compressed documentation file, rake-0.9.2.2/doc/rake.1.gz which could be directly downloaded here if you wish.
extractcode --replace-originals v0.9.2.2.zip
echo $?
1
In truth, most of the v0.9.2.2.zip archive is extracted, but only one file failed. The proposal is to change the return code to "2" in this case.
My test system is: Debian Linux, python 3.7.3, scancode-toolkit 30.1.0, installed from download of released Linux tar archive. However, the proposed bug fix for issue #2723 has also been applied, so that extractcode succeeds, for the rest of the archive.
Description
This case was originally proposed in the discussion of #2723.
There are a number of cases where extractcode fails to fully recursively unpack an archive. Embedded in the archive can be corrupt compressed content, or perhaps there are files that are recognized as archives, but an unarchiver is not configured for the current system. In these cases, extractcode partially succeeds and partially fails. (It unarchives some content but there is at least one recognized archive file seen in the recursion that it cannot unpack.)
In these cases, it would be helpful for the system using extractcode to know the difference between extractcode "utter failure" such as command line error or unable to do any work on the passed archive, and a partial unpack, where some elements are extracted but there is at least one failure along the way. The suggestion here is to use a different return code for this case.
Right now, extractcode returns "0" on success and "1" on failure. This issue proposes that extractcode keep track of any interim unpack failures, and use the return code of "2" if some unpacking is done, but at least one recursive unpack failed.
How To Reproduce
A current test case is that provided in #2723, repeated here:
The target archive is here. Within the Ruby Rake zipfile is what appears to be a compressed documentation file, rake-0.9.2.2/doc/rake.1.gz which could be directly downloaded here if you wish.
In truth, most of the v0.9.2.2.zip archive is extracted, but only one file failed. The proposal is to change the return code to "2" in this case.
My test system is: Debian Linux, python 3.7.3, scancode-toolkit 30.1.0, installed from download of released Linux tar archive. However, the proposed bug fix for issue #2723 has also been applied, so that extractcode succeeds, for the rest of the archive.