On 02/07/2021 13:08, Jaikiran Pai wrote:
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?
This is an area where treating a zip file as a virtual file system doesn't quite work. We may have to look at zipfs ignoring entries that contain "." or ".." name elements or have it throw an exception if they are encountered. I think the main thing is that the APIs and access behaves consistently.
-Alan
