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