[jira] [Updated] (LUCENE-6499) WindowsFS misses to remove open file handle if file is concurrently deleted

["Simon Willnauer (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simon Willnauer updated LUCENE-6499:
------------------------------------
    Attachment: LUCENE-6499.patch

here is a test and a fix for the problem. I am not super happy since we now sync on top of an IO operation but I don't think there is a much easier solution unless we wanna use like an array of locks and the hash of the path to lock on two stages.

> WindowsFS misses to remove open file handle if file is concurrently deleted
> ---------------------------------------------------------------------------
>
>                 Key: LUCENE-6499
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6499
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: modules/test-framework
>    Affects Versions: 5.1
>            Reporter: Simon Willnauer
>             Fix For: Trunk, 5.3
>
>         Attachments: LUCENE-6499.patch
>
>
> WindowsFs has some race conditions when files are concurrently opened and deleted. A file might be successfully opened while concurrently deleted which should be prevented by the WindowsFS with an IOException / access denied. The problem is that we try to remove the leaked file handle form the internal map on close which fails since we fail to read the key from the filesystem since it has already been deleted. This manifests in subsequent `access denied` exceptions even though all streams on the file are closed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org