Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: dotnet/android-libzipsharp
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: main
Choose a base ref
...
head repository: dotnet/android-libzipsharp
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 3.1.1_whence_patch
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 1 commit
  • 3 files changed
  • 1 contributor

Commits on Dec 2, 2024

  1. Fix the elusive invalid zip archive issue that has been a problem for… 

    … ages! (#142)

* Fix the elusive invalid zip archive issue that has been a problem for ages!

Fixes dotnet/android#8988

We had this odd corrupt zip file issue which kept cropping up on our Azure Pipelines builds.
We had no idea what caused it until now. Some of the data for the local headers of an item (not the central directory) would be written incorrectly. This would result in a zip which may or may not be extractable, it would depend on how resilient the software extracting the data would be.

So, what was happening here was that (sometimes) libzip would start writing some data (most likely the local file header) using our stream source callback, and it would seek a few bytes into the data and then tried to seek back to the beginning. The latter seek was done by giving the seek operation of the callback an offset of 0 which, unfortunately, was also used by the code as a guard as to whether or not to even perform the seek operation. The effect was that we ignored the seek to 0 and the stream remained at whatever the previous seek location was requested, thus corrupting data. It happened only on the very first entry, since that was the only one which would have position 0 within its range.

We discovered that just enabling the strict consistency checks would uncover the issue, so that has been enabled in
a number of unit tests. Once we did that it turns out we were writting the corrupt data ALL the TIME!.
Fixing up the seeking code to take into account that we might want to see to 0 fixed the issue.

* Bump to 3.3.0 due to ABI changes
    @dellis1972
    dellis1972 committed Dec 2, 2024
    Configuration menu
    Copy the full SHA
    b531339 View commit details
    Browse the repository at this point in the history
Loading