Or only catch the specific exception and only swallow that? But yeah,
this is something that should change as I see this "in the field" and
a more specific error message would short-circuit a lot of unnecessary
pain.
see: LUCENE-7959
Erick
On Wed, Sep 6, 2017 at 5:49 AM, Shawn Heisey <apa...@elyograg.org> wrote:
> On 9/4/2017 5:53 PM, Erick Erickson wrote:
>> Gah, thanks for letting us know. I can't tell you how often
>> permissions issues have tripped me up. You're right, it does seem like
>> there could be a better error message though.
>
> I see this code in NativeFSLockFactory, code that completely ignores any
> problems creating the lockfile, right before the point in the
> obtainFSLock method where Phil's exception came from:
>
> 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.
> }
>
> I think that if we replaced that code with the following code, the
> *reason* for ignoring the creation problem (file already exists) will be
> preserved. Any creation problem (like permissions) would throw a
> (hopefully understandable) standard Java exception that propagates up
> into what Solr logs:
>
> // If the lockfile already exists, we're going to do nothing.
> // If there are problems with that lockfile, they will be caught later.
> // If we *do* create the file here, exceptions will propagate upward.
> if (Files.notExists(lockFile))
> {
> Files.createFile(lockFile);
> }
>
> The method signature already includes IOException, so this doesn't
> represent an API change.
>
> Thanks,
> Shawn
>
