Update TestTooManyEntries to run non-manual

[Lance Andersen]

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)

 Best,
Lance

On Jan 28, 2023, at 11:10 AM, Eirik Bjørsnøs <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:

On Sat, Jan 28, 2023 at 4:47 PM Alan Bateman <Alan.Bateman at oracle.com<mailto: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.



[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/08b0ce4c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230128/08b0ce4c/oracle_sig_logo.gif>