When searching for the Zip64 end of central directory locator, pay attention to its fixed size.

[Numpsy]

#403 / #375 - the Zip64 end of central directory locator has a fixed 20 byte length, but the calls to LocateBlockWithSignature were specifying a fixed size of 0 and a dynamic size of 0x1000, which meant that the signature bytes could incorrectly be matched in a location other than where they should be (20 bytes prior to the end of central directory signature)

I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.

[Numpsy]

(Might also be worth adding an extra unit test with a file crafted to fall over 403)

[Numpsy]

Added a simple unit test that fails with the existing code and passes with the change

[piksel]

This seems valid. I was worried about compability with "special" files, like self-extractors etc. would suffer from the stricter search parameters, but I have not found any evidence of this. Sometimes it's hard to tell if things in this library are intentional or mistakes/unpolished.

[Numpsy]

I hadn't considered a different structure in self extractors, but I don't know enough about the differences to say either way.

[piksel]

@Numpsy Well, one of the interesting parts about the zip format is that, compared to most other file formats, it is basically read from the end. The "true" entry point into the data structure is the "end of central directory record". This means that you can prepend other data before the file entries, like for example a windows PE binary or an image. This means that a file can be both a valid .exe and a valid .zip at the same time.