[jira] [Updated] (VFS-748) TarProvider Incorrectly marks file IMAGINARY after garbage collection with WeakRefFilesCache

["Gary D. Gregory (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/VFS-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary D. Gregory updated VFS-748:
--------------------------------
    Summary: TarProvider Incorrectly marks file IMAGINARY after garbage collection with WeakRefFilesCache  (was: TarProvider Incorrectly marks file IMAGINARY after garbage collection with weakRefFilesCache)

> 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)