[
https://issues.apache.org/jira/browse/VFS-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001201#comment-17001201
]
Gary D. Gregory commented on VFS-748:
-------------------------------------
[~Kafalas],
Thank you for your report.
The best way forward here would be to provide a PR on GitHub which includes
your test.
> TarProvider Incorrectly marks file IMAGINARY after garbage collection with
> weakRefFilesCache
> --------------------------------------------------------------------------------------------
>
> Key: VFS-748
> URL: https://issues.apache.org/jira/browse/VFS-748
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: commons-vfs2.2.jar
> commons-compress-1.18.jar
> Reporter: Tim
> Priority: Major
> Attachments: TarBug.java, test.tar.gz
>
>
> 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)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
