ZipArchive constructor in the .NET framework produces inconsistent results on Windows 10 and Windows Server machines RRS feed

  • Question

  • The ZipArchive Class in the .NET framework v4.5.2 is behaving differently on Windows 10 and Windows Server 2012 machines.

    I have a sample .APK file from which I'm trying to construct a ZipArchive object as follows.

    using(var zipArchive = new ZipArchive(File.OpenRead("sample.apk")))
                    Console.WriteLine("Number of Entries: "+ zipArchive.Entries.Count);

    This works fine on a Windows 10 machine and no problems as expected because an .APK file is essentially a ZIP file. However, trying to construct a ZipArchive object from the same file on a Windows Server 2012 and 2008 machine throws the  exception "Number of entries expected in End Of Central Directory does not correspond to number of entries in Central Directory". Clearly, there is some underlying logic that is producing a false negative on the Windows Server machine as I was able to dissect the file and verify that the number of entries was indeed correct in the "End of Central Directory" section of the zip archive. This indicates that the System.IO.Compression library is producing inconsistent results for the same file on different platforms and could be potentially problematic if that is actually the case. Has anyone face similar issues with other libraries provided by the .NET framework?

    Thursday, January 25, 2018 7:20 PM

All replies

  • Well... There is one difference.

    In normal ZIP files, the number of entries in Central Directory is always equal to "the number of entries on this disk" in "the end of Central Directory" (and because multi-volume archive is not supported in .NET framework, this means the values are to be the same)

    For APK files, because they want to reduce build time, the APK file be generated will always have a few blank entries be appended on initial creation (so if a later build action need to add a few files, they can just add them to the blank entries instead of repacking everything from scratch). So the number of entries the runtime found on CD will nearly always be more than the number indicated on "end of CD". (Empty entries shouldn't increase "number of entries" record)

    Not sure if they removed this check because of this fact, or just skipped counting blank entries.

    Friday, January 26, 2018 1:41 AM