Rewriting to an already opened file fails on Windows

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a vector store from disk to read or write.
2. Close the vector store.
3. Try to open and rewrite.

What is the expected output? What do you see instead?

You'd expect this to work is the vector store was properly closed, instead
it causes a crash on Windows.

See VectorStoreWriterTest.java for the easiest ways to test this /
reproduce this in practice.

This seems to be a more basic Java / Windows issue. Please let me know if
I'm wrong about this, or if there is a usable workaround. Unfortunately I'm
marking this as a "WontFix" in the meantime.

Original issue reported on code.google.com by dwidd...@gmail.com on 24 Feb 2009 at 6:59

[GoogleCodeExporter]

Relisted as "Accepted" rather than "Wontfix", so that it shows up in the 
standard
view of known issues.

Original comment by dwidd...@gmail.com on 24 Feb 2009 at 7:00

• Changed state: Accepted

[GoogleCodeExporter]

I've dug up my XP machine and tried to recreate this problem. Here are some 
notes I've found on the way.

1. When I run "ant run-integration-tests" on Windows XP (which contains the 
VectorStoreWriterTest mentioned above) the test suite hangs with 0% processor 
use. I don't experience a crash, though. I've had difficultly attaching jdb to 
the test suite to determine where it hangs.
2. When I interrupt the test suite (ctrl-c) some files in the directory "tmp" 
were left open following the hang. This prevents cleanup of the directory "tmp" 
because rm cannot remove the files that are supposedly in use. When I try to 
delete the files the OS tells me that vector store infile was in use. So I 
investigated and found that VectorStoreTranslator was leaving some files open, 
which led to the fix in committed r387. Following this fix the OS tells me that 
the directory "tmp" itself is in use. I haven't found the cause for this 
problem but it may be related to the abrupt exit (in which case it isn't really 
a problem) or maybe it is from another forgotten file handle.
3. Next I'd kill the java VM and then delete the files. Now I can start over.

In summary: I haven't reproduced the crash, but I did fix a problem that might 
be related and I found another area to look at (the continued use of "tmp") 
that I'd like to learn more about. This also puts into question the premise 
that the vector store is properly closed, but I have no definite proof at the 
moment.

My current feeling is that FSDirectory (a Lucene file) may not be releasing a 
file lock or just leaving the file handle open. I haven't proven anything yet, 
so I don't want to jump to conclusions. But this is an area I'm looking toward 
for answers. Further, the javadoc for FSDirectory is rife with 
implementation-specific issues and workarounds for Windows which makes me even 
more suspicious.

If anyone knows of a good static analysis tool to find abandoned-while-opened 
file handles, please let me know.

Also: The file VectorStoreTranslater.java might be easier to find if named 
VectorStoreTranslator.java. I'm not about to move the files around without 
further input, but I did scratch my head for a long minute when I searched for 
the incorrect file name.

Original comment by ThomasCR...@gmail.com on 21 Nov 2010 at 7:40

[GoogleCodeExporter]

I fixed my problems with the integration test, but I couldn't reproduce this 
error using the VectorStoreWriter test without modification.

Original comment by ThomasCR...@gmail.com on 22 Nov 2010 at 8:39

[GoogleCodeExporter]

r414 makes VectorStoreWriterTest work on Windows.

This may be ready to close, please take another look.

Original comment by ThomasCR...@gmail.com on 5 Dec 2010 at 12:36

[GoogleCodeExporter]

QA should verify.

Original comment by ThomasCR...@gmail.com on 8 Dec 2010 at 3:18

• Changed state: Fixed