This does happen in the Java version (1.4.3), but I now have a better idea of what's going on. I felt really cool, wrote a big long explanation about it, and then just for kicks checked the code in the Repository. Guess what, it will be fixed in the next version. If you're interested, the issue is in the files() method, around line 219, of Index\SegmentReader.java; in version 1.4.3 there's no check if the file exists before adding it to the Vector.
Thanks, Monsur > -----Original Message----- > From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 03, 2005 1:26 AM > To: java-dev@lucene.apache.org > Subject: Re: Questions about DeleteFile method > > Judging from the method name, this is back in Lucene.Net, so > maybe this > is a bug in the .Net port. The .cfs file indicates that you are using > the compound index format, which means that *.fN files should not be > deleted explicitly like that. > I wonder if you see the same behaviour with Lucene (Java). > > Otis > > > --- Monsur Hossain <[EMAIL PROTECTED]> wrote: > > So after digging around FSDirectory's DeleteFile method, I noticed > > something > > curious. After an incremental index, the system tried to delete a > > lot of > > *.f* files (like _5.f1, _5.f2), which didn't exist on the file > > system. > > These files are named after the segment that is being deleted (for > > example, > > there does exist a _5.cfs file, which is deleted). Why its > trying to > > delete > > these files that don't exist? > > > > Also, when these files aren't found, DeleteFile throws an exception; > > the > > calling method traps this exception and adds the filename to the > > "deletable" > > file. This can lead to a lot of exceptions being thrown during a > > large > > indexing operation, which could incur a performance penalty. For > > performance reasons, should DeleteFile return a boolean (true if the > > file is > > deleted, false if not), which the calling method can then handle > > approriately? The calling method would still have to trap on the > > exception, > > but at least there'd be far fewer Exceptions thrown. > > > > Thanks, > > Monsur > > > > P.s. I haven't done any perf tests to verify this, it was just a > > thought. > > I'll look into pulling something together. > > > > ____________________________________________________________________ > Simpy -- simpy.com -- tags, social bookmarks, personal search engine > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
