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
