• Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: PC, OS: All

      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)

          [JENKINS-3053] Unable to delete SCM files

          mdonohue added a comment -

          Some process, probably some part of the previous build, is probably holding that
          DetermineAddress.obj file open, preventing the delete. If you get a tool like
          'unlocker' you can investigate further: http://ccollomb.free.fr/unlocker/

          mdonohue added a comment - Some process, probably some part of the previous build, is probably holding that DetermineAddress.obj file open, preventing the delete. If you get a tool like 'unlocker' you can investigate further: http://ccollomb.free.fr/unlocker/

          mdonohue added a comment -

          add self

          mdonohue added a comment - add self

          mdonohue added a comment -

          add in4tunio to cc list.

          mdonohue added a comment - add in4tunio to cc list.

          christopheM added a comment -

          I got regularly this problem (project unable to delete part of the workspace) on several hudson installation, all working on windows 7. I am currently on hudson 1.385 but have this problem since i am using hudosn (ie approx may 2010).

          This bug seems quite random, and always vanished if we wait enough time (or try to launch a build enough time).
          We can also delete the workspace by hand directly from windows file explorer and also get some strange behaviour such as messages saying:
          "I can not delete a file xxxx" and after acknowledging this windows error the file (or directory) finally get deleted.

          Another clue is that usually if rebooting the host, we (almost) always have to clean (fix) the file system.

          christopheM added a comment - I got regularly this problem (project unable to delete part of the workspace) on several hudson installation, all working on windows 7. I am currently on hudson 1.385 but have this problem since i am using hudosn (ie approx may 2010). This bug seems quite random, and always vanished if we wait enough time (or try to launch a build enough time). We can also delete the workspace by hand directly from windows file explorer and also get some strange behaviour such as messages saying: "I can not delete a file xxxx" and after acknowledging this windows error the file (or directory) finally get deleted. Another clue is that usually if rebooting the host, we (almost) always have to clean (fix) the file system.

          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.

          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.

          pjdarton added a comment -

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

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

          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.

          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.

          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"

          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"

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

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

            Unassigned Unassigned
            jfdionne jfdionne
            Votes:
            4 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: