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

[Jaikiran Pai]

Hello Lance,

On 02/07/21 4:42 pm, Lance Andersen wrote:
> 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"

Thank you for noticing this issue in my change and bringing this up. I 
have a question around this use case. Please consider a small variation 
to your example as below:

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));
             zos.closeEntry();
             zos.putNextEntry(new ZipEntry("/Hello.txt"));
             zos.write("Bye bye".getBytes(StandardCharsets.UTF_8));
             zos.closeEntry();

         }

Notice that I now have a zip/jar which has 2 differently named entries 
"../Hello.txt" and "/Hello.txt". This creates the archive without any 
issues and those 2 entries are noted in its listing. Now assuming 
someone walks over this jar using the ZipFileSystem, starting at root 
("/"), what should be the expected output? The path(s) returned will end 
up being "/" and "/Hello.txt" but which resource is expected to be 
served in this case? The one which has "Hello World" in it or the one 
which has "Bye bye"? This example can be extended a bit more by 
introducing a "./Hello.txt", in the jar, with yet another different 
content in that entry. Is there some specification for this that I can 
check and adapt the test case accordingly?

-Jaikiran