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 >interest? >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 >it... > >Sorry I couldn't help more, maybe somebody else can find the problem. > >Otis > 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?). Dmitry. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
