RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false [v2]

[Claes Redestad]

On Sun, 1 Nov 2020 23:41:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> To validate the test, requires info-zip which comes on Mac and linux. It is not included with windows. There are no issues if the Zip is created via java.util.zip or Zip FS
>> 
>> Ah, gotcha. I see and understand the use of the external zip now. This seem a bit fragile - maybe needs to be more graceful in case the system zip doesn't exist or doesn't do what you expect?
>
>> > To validate the test, requires info-zip which comes on Mac and linux. It is not included with windows. There are no issues if the Zip is created via java.util.zip or Zip FS
>> 
>> Ah, gotcha. I see and understand the use of the external zip now. This seem a bit fragile - maybe needs to be more graceful in case the system zip doesn't exist or doesn't do what you expect?
> 
> Zip is provided on Mac and Linux so unless the system is mis-configured, zip should be available on the path.  Are you suggesting to execute "zip -h" or "which zip" and  skip if zip is not there?  I could make it a manual test but thought given zip should be on linux and Mac that should be OK.  As long as the zip file is created, we are good to go.   I chose not to fall back to Zip FS (or java.util.zip)  to create the zip file as I know this will always pass.
> 
> Given the size of the file needed, it would be too large to check a file into the workspace.
> 
> Please let me know if you had another idea (Or prefer this to be a manual test)

Given the need to generate a 4Gb file on the fly I do feel this maybe ought to be a manual test, or maybe there's some annotation to ensure it's not run on systems with too little disk space (and no compatible zip).

-------------

PR: https://git.openjdk.java.net/jdk/pull/987