[
https://issues.apache.org/jira/browse/VFS-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132861#comment-15132861
]
Bernd Eckenfels commented on VFS-594:
-------------------------------------
I need to dig a bit deeper to give a detailed answer, but with 2.1-SN you can
use `manager.closeFilesystem(file.getFileSystem ())` to actually close the
overlay filesystem and remove all its entries from the cache. It will also
close the ZipFile (I think). I am not sure if it completely works in 2.0, lots
of fixes in that area are contained in the snapshot.
Using the nullcache does not work very well with overlay filesystems
(unfortunatelly).
> cache holds onto ZipFiles, which leak file handlers
> ---------------------------------------------------
>
> Key: VFS-594
> URL: https://issues.apache.org/jira/browse/VFS-594
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Sam Halliday
>
> The wonderful Java implementation of ZipFile opens up the file on instance
> creation. That's exceptionally wasteful on Linux but downright buggy on
> Windows, because Windows will then obtain an exclusive lock on that file.
> In ENSIME, this has the wonderful side effect of making compilation silently
> fail, because the compiler can't write out to the jar file, because it's
> being held by the IDE process.
> The references are being kept alive by the VFS cache. I'm going to try to
> disable it, as well as attempt as much manual closing of ZipFiles as I
> possibly can.
> Tracking from https://github.com/ensime/ensime-server/issues/1276
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
