Lucene - Core
  1. Lucene - Core
  2. LUCENE-5626

SimpleFSLockFactory "access denied" on windows.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.8, 4.9, 6.0
    • Component/s: core/store
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      This happened twice in jenkins:

      [lockStressTest2] Exception in thread "main" java.io.IOException:
      Access is denied
      [lockStressTest2] at
      java.io.WinNTFileSystem.createFileExclusively(Native Method)
      [lockStressTest2] at java.io.File.createNewFile(File.java:1012)
      [lockStressTest2] at
      org.apache.lucene.store.SimpleFSLock.obtain(SimpleFSLockFactory.java:135)
      

      My windows machine got struck by lightning, so I cannot fix this easily.

      1. LUCENE-5626.patch
        1 kB
        Uwe Schindler
      2. LUCENE-5626.patch
        0.8 kB
        Uwe Schindler

        Activity

        Hide
        Uwe Schindler added a comment - - edited

        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).

        Show
        Uwe Schindler added a comment - - edited 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).
        Hide
        Robert Muir added a comment -

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

        Show
        Robert Muir added a comment - Is it easy with the macro to increase the number of lock clients? Perhaps that is enough to trigger the issue.
        Show
        Dawid Weiss added a comment - See this post, interesting. http://stackoverflow.com/questions/10516472/file-createnewfile-randomly-fails
        Hide
        Robert Muir added a comment -

        Yes the NativeFSLockFactory already has a catch block for this.

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

        Show
        Robert Muir added a comment - Yes the NativeFSLockFactory already has a catch block for this. Interestingly enough, its code comment refers to MacOS X...
        Hide
        Uwe Schindler added a comment -

        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.

        Show
        Uwe Schindler added a comment - 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.
        Hide
        Uwe Schindler added a comment -

        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.

        Show
        Uwe Schindler added a comment - 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.
        Hide
        Uwe Schindler added a comment -

        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!

        Show
        Uwe Schindler added a comment - 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!
        Hide
        Robert Muir added a comment -

        Patch looks good. Thanks Uwe.

        Show
        Robert Muir added a comment - Patch looks good. Thanks Uwe.
        Hide
        Dawid Weiss added a comment -

        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.

        Show
        Dawid Weiss added a comment - 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.
        Hide
        Uwe Schindler added a comment -

        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.

        Show
        Uwe Schindler added a comment - 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.
        Hide
        Uwe Schindler added a comment -

        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.

        Show
        Uwe Schindler added a comment - 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.
        Hide
        Dawid Weiss added a comment -

        Access denied... why?

        Show
        Dawid Weiss added a comment - Access denied... why?
        Hide
        Uwe Schindler added a comment -

        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.

        Show
        Uwe Schindler added a comment - 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.
        Hide
        Uwe Schindler added a comment -

        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.

        Show
        Uwe Schindler added a comment - 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.
        Hide
        Uwe Schindler added a comment -

        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".

        Show
        Uwe Schindler added a comment - 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".
        Hide
        ASF subversion and git services added a comment -

        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

        Show
        ASF subversion and git services added a comment - 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
        Hide
        ASF subversion and git services added a comment -

        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

        Show
        ASF subversion and git services added a comment - 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
        Hide
        Uwe Schindler added a comment -

        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...

        Show
        Uwe Schindler added a comment - 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...
        Hide
        ASF subversion and git services added a comment -

        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

        Show
        ASF subversion and git services added a comment - 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
        Hide
        ASF subversion and git services added a comment -

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

        LUCENE-5626: Move changes entry

        Show
        ASF subversion and git services added a comment - Commit 1589813 from Uwe Schindler in branch 'dev/trunk' [ https://svn.apache.org/r1589813 ] LUCENE-5626 : Move changes entry
        Hide
        ASF subversion and git services added a comment -

        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

        Show
        ASF subversion and git services added a comment - 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
        Hide
        ASF subversion and git services added a comment -

        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)

        Show
        ASF subversion and git services added a comment - 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)
        Hide
        Uwe Schindler added a comment -

        Backported to 4.8 for respin.

        Show
        Uwe Schindler added a comment - Backported to 4.8 for respin.
        Hide
        Uwe Schindler added a comment -

        Close issue after release of 4.8.0

        Show
        Uwe Schindler added a comment - Close issue after release of 4.8.0

          People

          • Assignee:
            Uwe Schindler
            Reporter:
            Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development