On 15/03/13 09:50, Minto van der Sluis wrote:
Thanks Andy for your explanation. Seems indeed like I am hitting that
know bug :-(
Now I have to go through the hassle to build and test my modifications
on some other OS.
:-( indeed.
TDB testing islittered with e.g.
final String DIR = SystemTDB.isWindows
? ConfigTest.getTestingDirUnique()
: ConfigTest.getTestingDirDB() ;
Regards,
Minto
Op 15-3-2013 10:17, Andy Seaborne schreef:
On 15/03/13 08:48, Minto van der Sluis wrote:
Zooming in on rdf.jena.tdb.storage I see behaviour I noticed before. At
least on Windows TdbTcProvider.delete(..) does not properly clean up the
given directory. Instead of abusing TdbTcProvider in test cases for
doing the clean up I used Apache Common IO. However using Common IO
FileUtils.forceDelete(..) results in an exception. It seems like
something still keeps holding on to (some of) the files.
I guess you are running with a 64bit JVM. [1]
A "feature" of MS Windows is that you can't delete a memory mapped
file while the JVM is running even if you detach all the mapped
segments. "nuisance" would be too polite.
There are workarounds rumoured but the only one I know of that might
be reliable, and not tricks calling GC() twice in quick succession, is
to call Sun-JVM specific operations.
TDBs own test suite has to specifically create fresh directories for
each test on Windows.
Andy
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038
and several others. Once there was a popularity list of bugs and
features and this was steadily in the top 25.
One of the bug reports was a collecting point for attempts to
workaround this - but user comments thread does not seem to have
survived the transitions to the current trackers; at least, I can't
find them again.
