I agree, we should not ignore the return value here. I think throwing an
exception if it returns false is the right thing to do? Though, if it's
a checked exception, that's not a backwards compatible change...
Mike
"Nikolay Diakov" <[EMAIL PROTECTED]> wrote:
> I have briefly reviewed the SimpleFSLock of Lucene 2.1 and 2.2. I see
> that the lock release mechanism does not check the return value of
> delete:
>
> public void release() {
> lockFile.delete();
> }
>
> On most linux-es this can never return false, however under some windows
> FS if someone (a virus scanner) touches the file at the proper
> (improper) time, one may get a delete failure and get a false value. In
> the original code this means that the directory stays locked forever
> (unless someone does double unlocking or until a clearLock from the lock
> factory). For diagnosting purposes, it may be a good idea to throw an
> exception in that case. Alternatively, release() may return a boolean up
> the chain, however this may require more changes in the code using the
> release(). Just a suggestion.
>
> Cheers,
> Nikolay
>
> ---------------------------------------------------------------------
> 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]
