Yes, looks like clearLock should be changed to not throw the exception, but rather do a best effort - call delete() but don't respond to its return value. I'll change that on 3x, I'm not sure if a backport to 3.0.x is needed (doesn't seem to justify a 3.0.3 ...)
Shai On Wed, Jul 7, 2010 at 8:59 AM, Ted McFadden <t...@leximancer.com> wrote: > Hi, > > For Lucene 3.0.2, issue LUCENE-2421 ( > https://issues.apache.org/jira/browse/LUCENE-2421) changed > NativeFSLock.release to not raise an exception if a write.lock file could > not be deleted since the presence of the file itself does not mean a lock > is > held. > > Should NativeFSLockFactory.clearLock also be changed to not raise an > exception if it can't delete the write.lock file? The comments in the > clearLock method seem to suggest the method is really no longer necessary, > but IndexWriter.init can still call it. > > If the write.lock is held from deletion by antivirus or something as > described in LUCENE-2421, IndexWriter construction looks like it can fail > unnecessarily for the same reason: > > IndexWriter > IndexWriter.init > Directory.clearLock > NativeFSLockFactory.clearLock: > ... > if (lockFile.exists() && !lockFile.delete()){ > throw new IOException("Cannot delete " + lockFile); > } > > > We have seen this exception path once in the wild (on a Windows box). > > I can work around this with a custom LockFactory but thought I should check > if I'm reading the code right. > > Cheers, > > Ted > > > -- > Ted McFadden > Chief Engineer > > Leximancer Pty Ltd > Queensland, Australia > http://www.leximancer.com >
