RFR: 8222440: (zipfs) JarFileSystem does not correctly handle versioned entries if no root entry is present

[Lance Andersen]

Hi Christoph,

Overall, I think the changes look good.

Was there a reason that you did not leave the multi-release 9 test as is when you added the 10 test?

As far as removing the jar file, I would think that would still want to be done.  I understand why you did this, not sure what the standard is here as most tests try to do clean up

Best
Lance
> On Apr 16, 2019, at 4:50 PM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi,
> 
> please review a fix for an issue with zipfs/jarfs regarding multi-release jars.
> 
> The issue is observed when an mr-jar does have entries for certain files in the versioned subfolders but not in the main tree. This should be allowed as per JEP 238 [0]. So, say, if a jar file contains an entry '/META-INF/versions/11/file.txt' but not the entry 'file.txt', this will not correctly be visible when walking the jar file with jarfs. I discovered this when working on JDK-8222276 and saw a suspicious usage of IndexNode.keyOf() to create a virtual index node for the JarFileSystem lookup table. So I enhanced the test 'test/jdk/jdk/nio/zipfs/jarfs/JFSTester.java' to demonstrate the issue. The updated test case will fail with the current coding and works with the proposed fix.
> 
> Here are some details:
> JarFileSystem builds a lookup table to return for any jar entry its versioned entry, should it exist, in favor of the standard root entry. This is done by overriding ZipFileSystem's getInode() method and using a lookup table to return the correct versioned entry. The actual root inode is the key of this lookup table, which requires that it exists. If there is no root inode in the jar, there is code to create a virtual inode. But as it is right now, this does not work because a special singleton key node is used as virtual node which constantly changes its name. Furthermore, the node is not added to the jar file system node hierarchy. I enhanced this by correctly creating a 'virtual' root inode, making sure all parent directory inodes exist and if not creating and adding them into the jarfs/zipfs hierarchy to allow for iterating subdirectories.
> 
> I also enhanced 'test/jdk/jdk/nio/zipfs/jarfs/JFSTester.java' to demonstrate the issue. The test furthermore does not rely on files that are checked in in the source tree any longer but creates the test.jar by means of JarBuilder. I also don't delete test.jar in the test but leave it to jtreg to delete the scratch directory. That helps when analyzing test issues where scratch directory contents shall be retained.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222440
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222440.0/
> 
> Thanks in advance
> Christoph
> 
> [0] https://openjdk.java.net/jeps/238
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>