lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Serebrennikov <>
Subject Re: InputStream handling problem
Date Thu, 25 Apr 2002 03:57:37 GMT
Otis Gospodnetic wrote:

>I don't know, are you sure that what you are seeing really is a
>problem, that it is wrong to get rid of a file for which there is
>It sounds logical, but maybe Doug wrote something that we can't find
>that makes this an okay thing to do.
>If this is a bug I wonder how come more people haven't complained about
>Sorry I couldn't help more, maybe somebody else can find the problem.
I think originally the code was written to work on Unix, where deleting 
an open file is ok - it simply removes the directory entry and so one 
else can open the file any more. OS keeps track of the file readers and 
cleans up after the last reader has closed the file (or died). Later 
one, when the code was moved to DOS, there was a problem with this 
because DOS will refuse to delete a file it if is open. So the delete 
code would fail (I think File.delete() just returns false, no exceptions 
are thrown). To work with this, there is the "deleted" file which lists 
the segments that could be deleted (but weren't due to the fact that 
they were still open). Periodically, this file is checked and deletes 
are attempted again.

So, I think Otis is right - it's really not a "problem", besides being 
an interesting design problem that is. There is an issue of whether it 
is a good practice to make use of OS-specific behavior in this way. 
Obviously, the portability suffers. I'm not sure if there are 
performance arguments one way or another (Doug?).


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message