[
https://issues.apache.org/jira/browse/LUCENE-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16159786#comment-16159786
]
Robert Muir commented on LUCENE-7961:
-------------------------------------
We can of course add a test like LUCENE-7959, but I think its overkill.
The point is a filesystem can legally throw {{IOException("file already
there")}} from this method and the lockfactory will never deliver a
LockObtainedFailedException. Also its confusing today that we catch
AccessDenied to handle the sporatic windows case, and deliver "lock held
elsewhere" (even though we chain the exception). it could just be a permissions
error. And it can always be the case its just a leftover file.
> SimpleFSLockFactory should catch+box IOException (not
> FileAlreadyExistsException | AccessDeniedException)
> ---------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-7961
> URL: https://issues.apache.org/jira/browse/LUCENE-7961
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-7961.patch
>
>
> SimpleFSLockFactory will only convert {{FileAlreadyExistsException |
> AccessDeniedException}} from Files.createFile() into
> LockObtainFailedException. Neither of these are guaranteed from the API, only
> {{IOException}}.
> I think SimpleFSLockFactory should box any IOException from
> Files.createFile() into a LockObtainFailedException instead of just these two
> optional ones. It is simpler and more consistent behavior, even if its just
> theoretical problem for some FileSystem impl that doesn't throw these.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
