Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Duplicate
    • Component/s: subversion-plugin
    • Labels:
      None
    • Environment:
      Platform: PC, OS: All
    • Similar Issues:

      Description

      When our projects are under source code management(in our case SVN) an error
      occurs while trying to delete the associated project workspace before the
      checkout. This always leads to a failed project and it forces us to do the
      remove workspace and checkout directly from the execute shell. It happens
      randomly, file permissions allow us to delete the files and there is no other
      concurrent process that could have a handle on these files.

      Hudson is at the latest version on a Windows Server Enterprise 2007 machine.

      started
      FATAL: Unable to delete
      D:\hudson_config\jobs\Trunk\workspace\trunk\win32\DebuggingApps\obj\netborder_win32_vc8\DetermineAddress.obj
      java.io.IOException: Unable to delete
      D:\hudson_config\jobs\Trunk\workspace\trunk\win32\DebuggingApps\obj\netborder_win32_vc8\DetermineAddress.obj
      at hudson.Util.deleteFile(Util.java:212)
      at hudson.Util.deleteRecursive(Util.java:244)
      at hudson.Util.deleteContentsRecursive(Util.java:178)
      at hudson.Util.deleteRecursive(Util.java:243)
      at hudson.Util.deleteContentsRecursive(Util.java:178)
      at hudson.Util.deleteRecursive(Util.java:243)
      at hudson.Util.deleteContentsRecursive(Util.java:178)
      at hudson.Util.deleteRecursive(Util.java:243)
      at hudson.Util.deleteContentsRecursive(Util.java:178)
      at hudson.Util.deleteRecursive(Util.java:243)
      at hudson.Util.deleteContentsRecursive(Util.java:178)
      at hudson.Util.deleteRecursive(Util.java:243)
      at hudson.Util.deleteContentsRecursive(Util.java:178)
      at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:460)
      at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:405)
      at hudson.FilePath.act(FilePath.java:389)
      at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:398)
      at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:347)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:681)
      at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:264)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:238)
      at hudson.model.Run.run(Run.java:842)
      at hudson.model.Build.run(Build.java:88)
      at hudson.model.ResourceController.execute(ResourceController.java:70)
      at hudson.model.Executor.run(Executor.java:90)

        Attachments

          Issue Links

            Activity

            Hide
            pjdarton pjdarton added a comment -

            The usual cause of this sort of problem on Windows is either the Windows Search service indexing the files that Hudson/Jenkins is trying to delete, or the Anti-Virus trying to check the files that Hudson/Jenkins is trying to delete.

            However, I've found that on Windows 7, configuring both of those to leave well alone isn't enough to prevent this.
            JENKINS-10905 is reporting the same kind of issue.

            Show
            pjdarton pjdarton added a comment - The usual cause of this sort of problem on Windows is either the Windows Search service indexing the files that Hudson/Jenkins is trying to delete, or the Anti-Virus trying to check the files that Hudson/Jenkins is trying to delete. However, I've found that on Windows 7, configuring both of those to leave well alone isn't enough to prevent this. JENKINS-10905 is reporting the same kind of issue.
            Hide
            pjdarton pjdarton added a comment -

            I have a prospective fix for this in JENKINS-15331.

            Show
            pjdarton pjdarton added a comment - I have a prospective fix for this in JENKINS-15331 .
            Hide
            danielbeck Daniel Beck added a comment -

            Resolving as duplicate of JENKINS-15331 as that's basically the same issue and has more watchers.

            As the other is about working around Windows file locking issues not in the domain of Jenkins, I suggest any bug reports need to show that it's actually Jenkins holding the file handle preventing deletion – the chance of this being some random Windows process going nuts is just too big. sysinternals tools should help with that.

            Show
            danielbeck Daniel Beck added a comment - Resolving as duplicate of JENKINS-15331 as that's basically the same issue and has more watchers. As the other is about working around Windows file locking issues not in the domain of Jenkins, I suggest any bug reports need to show that it's actually Jenkins holding the file handle preventing deletion – the chance of this being some random Windows process going nuts is just too big. sysinternals tools should help with that.
            Hide
            pjdarton pjdarton added a comment -

            FYI: Jenkins is perfectly capable of locking files open itself, e.g. someone looking at the "workspace" of a job at the same time that the job is trying to wipe that workspace. Not sure I'd call that a "bug" tho' - it's more an inescapable result of the way the Windows filesystem works (or "fails to work", depending on your point of view).
            That said, I'd agree that, most of the time, this kind of thing is caused by "some random Windows process going nuts"

            Show
            pjdarton pjdarton added a comment - FYI: Jenkins is perfectly capable of locking files open itself, e.g. someone looking at the "workspace" of a job at the same time that the job is trying to wipe that workspace. Not sure I'd call that a "bug" tho' - it's more an inescapable result of the way the Windows filesystem works (or "fails to work", depending on your point of view). That said, I'd agree that, most of the time, this kind of thing is caused by "some random Windows process going nuts"
            Hide
            danielbeck Daniel Beck added a comment -

            Right, I'm with you there: Jenkins isn't magically excluded from messing with files. That's not what I'm saying at all. But having the devs hunt ghosts because you have a nasty antivirus on your server isn't a solution either. That's why I'm saying that reporters should be able to show that Jenkins itself is the culprit (something that should be possible given reasonable effort with Process Explorer etc.). Everything else should be covered by JENKINS-15331 (I can't help but wonder whether that's also what Windows itself does when it takes forever to delete a single, tiny file!).

            Show
            danielbeck Daniel Beck added a comment - Right, I'm with you there: Jenkins isn't magically excluded from messing with files. That's not what I'm saying at all. But having the devs hunt ghosts because you have a nasty antivirus on your server isn't a solution either. That's why I'm saying that reporters should be able to show that Jenkins itself is the culprit (something that should be possible given reasonable effort with Process Explorer etc.). Everything else should be covered by JENKINS-15331 (I can't help but wonder whether that's also what Windows itself does when it takes forever to delete a single, tiny file!).

              People

              • Assignee:
                Unassigned
                Reporter:
                jfdionne jfdionne
              • Votes:
                4 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: