<div dir="ltr"><div dir="ltr">On Sat, Jan 28, 2023 at 4:47 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The intention of the test was exercise a multi-GB CEN. So I think it<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
would be great if it could be re-written as an automatic test but I <br>
think it should be a real ZIP file, make use of sparse files might help.<br></blockquote><div><br></div><div>Alan,</div><div><br></div><div>Yes, this change does exploit some knowledge of the internals of ZipFile. Specifically it assumes that:</div><div><br></div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>WDYT?</div><div><br></div><div>Eirik. </div><div><br></div><div> </div></div></div>