[
https://issues.apache.org/jira/browse/LUCENE-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-7959:
--------------------------------
Description:
This is one of those small changes that would save a lot of pain for end users.
Let's say that there's a permissions issue with the index dir. The user will
get "NoSuchFileException: write.lock" but not understand why the lock file is
missing (its because it could not be created). This is an unhelpful/misleading
error message (recent user's list discussion about this).
The problem is that when we try to create the lock file we swallow _all_
exceptions, not just the one we don't care about (Thanks [~elyograg] for
pointing this out).
{{
try {
Files.createFile(lockFile);
} catch (IOException ignore) {
// we must create the file to have a truly canonical path.
// if it's already created, we don't care. if it cant be created, it will
fail below.
}
}}
It fails later with NoSuchFileException, which does not provide enough
information.
was:
This is one of those small changes that would save a lot of pain for end users.
Currently, any failure to obtain the lock reports:
"Lock held by this virtual machine: " + realPath
or
"Lock held by another program: " + realPath
Let's say that there's a permissions issue with the index dir. This is an
unhelpful/misleading error message (recent user's list discussion about this).
The problem is that when we try to create the lock file we swallow _all_
exceptions, not just the one we don't care about (Thanks [~elyograg] for
pointing this out).
{{
try {
Files.createFile(lockFile);
} catch (IOException ignore) {
// we must create the file to have a truly canonical path.
// if it's already created, we don't care. if it cant be created, it will
fail below.
}
}}
It fails later with one of the above error messages.
> Throw more helpful error messages from failures in obtainFSLock, at least in
> NativeFSLockFactory
> ------------------------------------------------------------------------------------------------
>
> Key: LUCENE-7959
> URL: https://issues.apache.org/jira/browse/LUCENE-7959
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
> Attachments: LUCENE-7959_untested.patch
>
>
> This is one of those small changes that would save a lot of pain for end
> users.
> Let's say that there's a permissions issue with the index dir. The user will
> get "NoSuchFileException: write.lock" but not understand why the lock file is
> missing (its because it could not be created). This is an
> unhelpful/misleading error message (recent user's list discussion about this).
> The problem is that when we try to create the lock file we swallow _all_
> exceptions, not just the one we don't care about (Thanks [~elyograg] for
> pointing this out).
> {{
> try {
> Files.createFile(lockFile);
> } catch (IOException ignore) {
> // we must create the file to have a truly canonical path.
> // if it's already created, we don't care. if it cant be created, it
> will fail below.
> }
> }}
> It fails later with NoSuchFileException, which does not provide enough
> information.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
