|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
After searching my logfiles I found an instance of it occurring with Jenkins 1.579 using integrity-plugin 1.25 on 09-sep-2014. At the time when the issue occurred there was no active background process like an AV scanner locking the files in the directory. I would be inclined to think that, if anything was locked at all at this time, it was locked by a thread inside the Jenkins process (or one of its plugins).
java.nio.file.DirectoryNotEmptyException: [...]
at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source)
at java.nio.file.Files.delete(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at hudson.Util.deleteFile(Util.java:247)
at hudson.Util.deleteRecursive(Util.java:310)
at hudson.Util.deleteContentsRecursive(Util.java:212)
at hudson.Util.deleteRecursive(Util.java:301)
at hudson.Util.deleteContentsRecursive(Util.java:212)
at hudson.FilePath$13.invoke(FilePath.java:1108)
at hudson.FilePath$13.invoke(FilePath.java:1105)
at hudson.FilePath.act(FilePath.java:918)
at hudson.FilePath.act(FilePath.java:896)
at hudson.FilePath.deleteContents(FilePath.java:1105)
at hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:280)
at hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:25)
at hudson.FilePath.act(FilePath.java:918)
at hudson.FilePath.act(FilePath.java:896)
at hudson.scm.IntegritySCM.checkout(IntegritySCM.java:789)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1253)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1745)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Retrying after 10 seconds
The 2nd retry (after 10 seconds) was successful:
Populating clean workspace...
Successfully checked out 3172 files!
The exception occurred after the PTC Integrity SCM plugin executed "si projectinfo" and "si viewproject" and Jenkins outputs the message "A clean copy is requested; deleting contents of %WORKSPACE%" (where %WORKSPACE% is a placeholder for the workspace directory of the job. The next log file message after "Retrying after 10 seconds" is "Change Log: %WORKSPACE%/changes".
(Please note that at least one user observed this issue with a different SCM than PTC Integrity).
By the way: Is the SCM plugin executed in the same or in a different thread than the function hudon.util.deleteRecursive?