RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v4]

[Alan Bateman]

On Fri, 2 Jul 2021 11:08:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge latest from upstream master branch to bring in fixes that might help fix the unrelated tier1 failures in Github Actions job runs
>>  - implement review suggestions:
>>     - reduce the toString() calls by creating a helper
>>     - fs.getPath("/") instead of fs.getRootDirectories().iterator().next()
>>  - implement review suggestion - move isSelfOrParent to ZipPath class
>>  - 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside
>
> Hi Jaikiran,
> 
> Consider:
> 
> 
>         try (var os = Files.newOutputStream(ZIPFILE);
>              ZipOutputStream zos = new ZipOutputStream(os)) {
>             zos.putNextEntry(new ZipEntry("../Hello.txt"));
>             zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
>         }
> 
> 
> With your proposed fix, you will only return "/" when you walk the the Zip file and we should also return "/Hello.txt"
> 
> If. you resolve the path when the Inode entry is created:
> 
>            ` name(new ZipPath(null, normalize(name), true).getResolvedPath());`
> 
> That should address the issue and also allow you to access the entry.

I discussed this issue with @LanceAndersen and I think we are in agreement that a zip file system needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  The other options on the table (including Lance's origin prototype fix and the proposal in this PR) lead to anomalies. So I think we should close this PR and restart JDK-8251329.  @jaikiran Are you okay this this? JDK-8251329 is still assigned to JDK-8251329 and has a patch with the changes that we think are the right way for newFileSystem to reject ZIP files that have entries in the CEN that can't be used for files in a file system.

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

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