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

[Lance Andersen]

On Mon, 26 Jul 2021 09:52:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This change looks fine to me. I was unsure how the writing/creating entries with `.` or `..` with `ZipFileSystem` would behave in context of this change, so I gave this a try locally with the changes from this PR:
> 
> ```
> try (FileSystem zipfs = FileSystems.newFileSystem(ZIPFILE)) {
>             final Path[] paths = new Path[]{
>                     zipfs.getPath("./Hello.txt"),
>                     zipfs.getPath("../../../Hello.txt"),
>                     zipfs.getPath("../Hello.txt")};
>             for (int i = 0; i < paths.length; i++) {
>                 try (OutputStream os = Files.newOutputStream(paths[i])) {
>                     os.write(("Hello " + i).getBytes(StandardCharsets.UTF_8));
>                 }
>             }
>         }
> ```
> 
> This code runs fine and it ends up creating (just one) CEN entry for `Hello.txt`:
> 
> ```
> JTwork/scratch/zipfsDotDotTest.zip
>   Length      Date    Time    Name
> ---------  ---------- -----   ----
>         7  07-26-2021 15:07   Hello.txt
> ```
> 
> In other words, the `ZipFileSystem` doesn't end up creating a zip file which is then rejected by `ZipFileSystem` when creating a new filesystem using `Files.newFileSystem`. That's a good thing.


With the exception of creating the Inodes table,  Zip FS always calls ZipPath::getResolvedPath for access to Zip entries.  So there is no issues with the creation and access of entries in the case above

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

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