[
https://issues.apache.org/jira/browse/LUCENE-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16156433#comment-16156433
]
Erick Erickson commented on LUCENE-7959:
----------------------------------------
OK, maybe I get it now. Credit my slow uptake to slightly different versions
from the original problem statement and not looking carefully enough at the
code.
Playing around on my Mac, I get what _I_ expected at least:
Caused by: java.nio.file.AccessDeniedException:
which is pretty clear.
The original problem reported:
Caused by: java.nio.file.NoSuchFileException:
and the OP said "it was a permissions issue". So I jumped to conclusions. The
implementation on the original statement throws a different error..... Or I
didn't reproduce the right conditions. Or....
Neither of them ever got to the two hand-crafted error messages about a lock
being held by another process or virtual machine, I jumped over the
toRealPath() line and focused on the lines above them, which with an un-careful
reading looked like it swallowed all exceptions. Which actually it does but it
doesn't matter since the toRealPath line is where the error is thrown from.
Just like some guy named Muir said.... Siiiigggghhhhh.
So anything we can add safely I'm all for.
Sorry for the noise...
> 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.patch, 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]
