[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559908#action_12559908
]
Grant Ingersoll commented on LUCENE-1050:
-----------------------------------------
I agree, it can be fixed by the SpellChecker, but it still seems like an error
to throw an exception just b/c you try to delete something that doesn't exist,
especially since the release() mechanism doesn't say what will happen if it is
called when a lock doesn't exist.
The fix in the lock is really simple, too:
{code}
if (lockFile.exists() && !lockFile.delete()){
throw...
}
{code}
I vote for fixing both cases.
> SimpleFSLockFactory ignores error on deleting the lock file
> -----------------------------------------------------------
>
> Key: LUCENE-1050
> URL: https://issues.apache.org/jira/browse/LUCENE-1050
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
> Affects Versions: 2.2
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 2.3
>
> Attachments: LUCENE-1050.patch
>
>
> Spinoff from here:
> http://www.gossamer-threads.com/lists/lucene/java-user/54438
> The Lock.release for SimpleFSLockFactory ignores the return value of
> lockFile.delete(). I plan to throw a new LockReleaseFailedException,
> subclassing from IOException, when this returns false. This is a very minor
> change to backwards compatibility because all methods in Lucene that release
> a lock already throw IOException.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
