[VFS-748] TarProvider Incorrectly marks file IMAGINARY after garbage collection with WeakRefFilesCache

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.2
• Fix Version/s: 2.8.0

Environment

commons-vfs2.2.jar

commons-compress-1.18.jar

• Assignee: Unassigned
• Reporter: Tim
• Created: 03/Dec/19 17:48
• Updated: 02/Nov/20 02:07
• Resolved: 02/Nov/20 02:07

Description

A Tar FileObject becomes unusable once it is removed from the filesCache.  The example provided here uses the the WeakRefFilesCache but I suspect the bug is not limited to this cache type only, since it is the recreation of the entry after removal that is flawed.

 

The following code snippet will repeatedly access the the tarball until garbage collection occurs.  When this happens the cache entry is dropped but upon reaccess, a new cache entry is created that incorrectly marks the file as "IMAGINARY".  All subsequent access to this file is are not possible in the VM.

 

Output from the class provided looks like this....

97
98
99
100
tgz:file:///C:/env/ws/vfsTarBug/target/classes/test.tar.gz!/ did not exist

 

The number of successful iterations may vary depending upon the behavior of the GC.

Tracing the run, the culprit appears to be a createFile method which hard codes the tarExists argument to false when it should be true.  The stack trace for this appears below. 

at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)   at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:320)   - locked <0x53d2> (a org.apache.commons.vfs2.provider.tar.TarFileSystem)   at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:300)   at org.apache.commons.vfs2.provider.AbstractFileSystem.getRoot(AbstractFileSystem.java:274)   at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem(AbstractLayeredFileProvider.java:82)   - locked <0x53e2> (a org.apache.commons.vfs2.provider.tar.TarFileProvider)   at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile(AbstractLayeredFileProvider.java:56)   at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:711)   at org.pentaho.di.core.vfs.ConcurrentFileSystemManager.resolveFile(ConcurrentFileSystemManager.java:91)   at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:648)

Issue Links

• links to: GitHub Pull Request #97