Update TestTooManyEntries to run non-manual

[Eirik Bjørsnøs]

On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen <lance.andersen at oracle.com>
wrote:

> I think it is fine to move the validation immediately following findEND()
> though I am not sure there is a big win overall.
>
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version of the test).   I would prefer to avoid
> having another place where we have  duplicate code creating a CEN et al as
> it is another maintenance point.
>
> One option is to look at, is to store a zip in a byte array and modify the
> cenlen offset(you would want to provide the steps that were used to create
> the zip/byte array, I can provide you a trivial example if interested)
>

Thanks Lance!

This inspired me to update the PR with the following changes:

- Make "real" ZIP files using ZipOutputStream as suggested, avoiding
duplicating ZIP format internals
- Put one entry in the ZIP files instead of being empty
- Surgically update the CEN size in the END record to the desired value
- Remove all code to create and test ZIP64 files. What we are testing here
is rejection of certain CEN values, not how they are parsed

The test case for the "big but valid" ZIP is updated to detect that the CEN
size is rejected for being invalid (but not too large). ZipFIle is updated
accordingly to move the CEN size checking closer to the other tests (after
the zero-entry-short-circuit test)

While the ZIPs are still not GB-huge, and they are still invalid, the test
now at least asserts them as such.

What do you think of this update?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/2f84a335/attachment.htm>