<div dir="ltr"><div dir="ltr">On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen <<a href="mailto:lance.andersen@oracle.com">lance.andersen@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">



<div style="overflow-wrap: break-word;">
I think it is fine to move the validation immediately following findEND() though I am not sure there is a big win overall.
<div><br>
</div>
<div>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).   </div></div></blockquote><div><br></div><div>Hi, </div><div><br></div><div>I  updated the PR to "inflate" the CEN such that its size on disk matches the size stated in the END record. As suggested by Alan, this is done using sparse files, the actual disk usage is kept low.</div><div><br></div><div>While a ZIP with a zero-padded CEN is still not technically valid, the END record is now at least valid with respect to its offset. This allows us to test the validation of the various END record validation scenarios independently and without updating the ZipFile validation order to facilitate the testing.</div><div><br></div><div>There are now three test methods in the test, one for each of the possible ZipExceptions thrown during END record validation.</div><div><br></div><div>Cheers,</div><div>Eirik.</div><div><br></div></div></div>