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 <eir...@gmail.com<mailto:eir...@gmail.com>> wrote: On Sat, Jan 28, 2023 at 4:47 PM Alan Bateman <alan.bate...@oracle.com<mailto:alan.bate...@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@home] Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com<mailto:lance.ander...@oracle.com>
