Update TestTooManyEntries to run non-manual

[Eirik Bjørsnøs]

On Sat, Jan 28, 2023 at 4:47 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> The intention of the test was exercise a multi-GB CEN. So I think it
>
would be great if it could be re-written as an automatic test but I
> think it should be a real ZIP file, make use of sparse files might help.
>

Alan,

Yes, this change does exploit some knowledge of the internals of ZipFile.
Specifically it assumes that:

1: ZipFile seeks to the end of the JAR where it parses the End of central
directory header, then seeks backward to parse an optional Zip64 End of
central directory record / locator. At this point the CEN size is known.
2: That a too-large CEN size (obtained from ZIP64 or the normal end-of-cen
record) will be rejected early, before any attempt of reading the CEN or
other contents of the ZIP.
3: That ZipFIle will treat a ZIP file starting with an End of Central
directory (ZIP64 or not) as empty, short-circuiting any checking of invalid
CEN sizes.

Based on these assumptions, the test knows as a fact that any data up to
and including the CEN is never read by ZipFile. It seems a bit wasteful to
create multiple GBs of data which we know will never be read?

If you still prefer the test to use ZIPs which are valid from top to
bottom, I can take a stab at making that faster than the current test.

WDYT?

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