On Mon, 26 Jul 2021 09:52:09 GMT, Jaikiran Pai <j...@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
