OK I've opened this issue:
https://issues.apache.org/jira/browse/LUCENE-1050
Mike
"Michael McCandless" <[EMAIL PROTECTED]> wrote:
> "Nikolay Diakov" <[EMAIL PROTECTED]> wrote:
>
> > I see you do the wrapping in a RuntimeException trick. Perhaps you
> > can introduce a special exception der
"Nikolay Diakov" <[EMAIL PROTECTED]> wrote:
> I see you do the wrapping in a RuntimeException trick. Perhaps you
> can introduce a special exception derived from RuntimeException that
> you would throw in that case. It would basically mean "The
> underlying FS does something we cannot tolerate so
I see you do the wrapping in a RuntimeException trick. Perhaps you can
introduce a special exception derived from RuntimeException that you
would throw in that case. It would basically mean "The underlying FS
does something we cannot tolerate so we fail fast."
--Nikolay
Michael McCandless wro
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 Simpl
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
