Hi,
this is almost impossible to reproduce here locally. It is also a concurrency issue on windows. The problem is: if there is already something else trying to create the file, Windows generally responds with "Access is denied".

I think we should catch IOException in the obtain() method and handle this in a similar way like in NIOFSDir (return false, so lock was not aquired successfully).

I will provide a patch after trying to reproduce this on windows (by making filesystem and cpu busy).

Is it easy with the macro to increase the number of lock clients? Perhaps that is enough to trigger the issue.

See this post, interesting.
http://stackoverflow.com/questions/10516472/file-createnewfile-randomly-fails

Yes the NativeFSLockFactory already has a catch block for this.

Interestingly enough, its code comment refers to MacOS X...

Simple patch, doing the same Exception handling in obtain() like with NativeFSLockFactory.

This bug is not new, it exists as long as SimpleFSLockFactory exists. But it only happens on Windows and SimpleFSLF is no longer the default, so no need to hold 4.8.

See this post, interesting. http://stackoverflow.com/questions/10516472/file-createnewfile-randomly-fails

Thanks. Virus scanner or Indexer are not a problem on Jenkins, as they are disabled there. Otherwise the tests never pass The same on my local machine, I excluded all directories that are development from virus and indexer.

Interestingly enough, its code comment refers to MacOS X...

But it applies to Windows, too! If I disable it, it fails on my machine, too!

Patch looks good. Thanks Uwe.

It would be interesting to see what GetLastError shows, but for this you'd have to access winapi (via jna or something alike). I can't reproduce this locally, unfortunately.

This patch adds the "failureReason" like NativeFSLF does. This allows LockFactory throw the real failure after the locking failed. I don't like this code (looks like a hack), but this would make it consistent.

It would be interesting to see what GetLastError shows, but for this you'd have to access winapi (via jna or something alike). I can't reproduce this locally, unfortunately.

Very simple: "Access denied". The JNI code transforms GetLastError to a string and throws it as IOException.

Access denied... why?

Windows responds with this error code whenever a file is opened by another or the same process and you want to change the directory entry/inode/whatever of a file. Quite common, nothing special.

Some comment from StackOverflow: http://stackoverflow.com/questions/4312568/what-causes-writefile-to-return-error-access-denied

There is about a dozen different situations that might result in ERROR_ACCESS_DENIED. Internally, all WriteFile does is call NtWriteFile and map its (somewhat meaningful) NTSTATUS error code into a less meaningful HRESULT.

Among other things, ERROR_ACCESS_DENIED could indicate that the file is on a network volume and something went wrong with write permissions, or that the file is really not a file but a directory.

In fact this is a major pain and goes back to MS DOS times... If you at some time used the Win32 API, you know that whenever windows does not know how to handle a file it returns ERROR_ACCESS_DENIED on GetLastError (0x5). This is just the error code for, "everything DOS never supported".

Commit 1589394 from Uwe Schindler in branch 'dev/trunk'
[ https://svn.apache.org/r1589394 ]

LUCENE-5626: Fix bug in SimpleFSLockFactory's obtain() that sometimes throwed IOException (ERROR_ACESS_DENIED) on Windows if the lock file was created concurrently

Commit 1589397 from Uwe Schindler in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1589397 ]

Merged revision(s) 1589394 from lucene/dev/trunk:
LUCENE-5626: Fix bug in SimpleFSLockFactory's obtain() that sometimes throwed IOException (ERROR_ACESS_DENIED) on Windows if the lock file was created concurrently

As we respin 4.8, I will backport this one, too, because otherwise it could happen that somebody (like me) hit this while smoke testing...

Commit 1589811 from Uwe Schindler in branch 'dev/branches/lucene_solr_4_8'
[ https://svn.apache.org/r1589811 ]

Merged revision(s) 1589397 from lucene/dev/branches/branch_4x:
Merged revision(s) 1589394 from lucene/dev/trunk:
LUCENE-5626: Fix bug in SimpleFSLockFactory's obtain() that sometimes throwed IOException (ERROR_ACESS_DENIED) on Windows if the lock file was created concurrently

Commit 1589813 from Uwe Schindler in branch 'dev/trunk'
[ https://svn.apache.org/r1589813 ]

LUCENE-5626: Move changes entry

Commit 1589814 from Uwe Schindler in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1589814 ]

Merged revision(s) 1589813 from lucene/dev/trunk:
LUCENE-5626: Move changes entry

Commit 1589824 from Uwe Schindler in branch 'dev/branches/lucene_solr_4_8'
[ https://svn.apache.org/r1589824 ]

Merged revision(s) 1589814 from lucene/dev/branches/branch_4x:
Merged revision(s) 1589813 from lucene/dev/trunk:
LUCENE-5626: Move changes entry (merge props only)

Backported to 4.8 for respin.

Close issue after release of 4.8.0