Capture error details from SharpZipLib for invalid ZIPs #2287
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
We continue to have occasional difficulties with ZIP file validation. #2285 highlights an issue of discrepant redundant data in the local file header versus the central directory.
These issues are difficult to diagnose. In 1.22.6, the exceptions look like:
And in HEAD, we have:
These are pretty generic errors, which don't tell us much other than something is wrong with the ZIP. Lots of leg work is left to do to figure out what's wrong.
Changes
Now we capture more details from SharpZipLib, allowing us to specify which entry in the ZIP had a problem, as well as which validation step was being done and the detailed message from the validation function:
At a code level this is fairly awkward as error reporting goes.
ZipFile.TestArchive
doesn't throw exceptions and it returns only abool
. To capture its error messages, we need to pass a delegate as its third parameter, which receives incremental status updates as it goes through each file. When it finds an error, the delegate is called with the error message, and we save it off and use it for our return parameter.Not a fix for #2285, but it's probably the closest we'll get.