Can you provide more details that would make this a repeatable bug?

The stack trace shows you are using the command line git implementation. That implementation has no known problems with leaving files open. If you can provide a repeatable case, it has a much better chance of being investigated.

The JGit implementation has known problems with leaving files open (see JENKINS-19994).

There is also a risk that some other program is keeping the files open. There were cases in the past where a virus scanner prevented a directory from being deleted because it was keeping one or more files open from the directory.

Closing as "Cannot Reproduce" after a month of waiting for a response from the original submitter.

Hi,
I face same issue :
It was working really until yesterday on a specific job (no changes on jenkins configuration for several weeks)

remark :
Other jobs are still working for the moment (with the same command run on their own git repo).

=====================
Error with StackTrace
=====================
Manually triggered by user anonymous for Gerrit: https://MY_GIT:8080/607665
Building in workspace <http://MY_JENKINS:8080/jenkins/job/AR_VA_GerritVoter/ws/>
> git.exe rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
> git.exe config remote.origin.url ssh://MY_GIT:29418/sandbox/MY.git
Fetching upstream changes from ssh://MY_GIT:29418/sandbox/MY.git
> git.exe --version
> git.exe fetch --tags --progress ssh://MY_GIT:29418/sandbox/MY.git refs/changes/65/607665/1
> git.exe rev-parse "c68be008cc694ffc7fa87e28baaf86245b696c1a^

"
> git.exe rev-list 445b38d8c3bbf8d5ef30f811b2c148fb356308ce
> git.exe tag -a -f -m Jenkins Build #359 jenkins-AR_VA_GerritVoter-359
Cleaning workspace
> git.exe rev-parse --verify HEAD
Resetting working tree
> git.exe reset --hard
> git.exe clean -fdx
FATAL: Command "git.exe clean -fdx" returned status code 1:
stdout: Removing com.sap.hilo.desktop.overlay/target/

stderr: warning: failed to remove com.sap.hilo.desktop.overlay/target/

hudson.plugins.git.GitException: Command "git.exe clean -fdx" returned status code 1:
stdout: Removing com.sap.hilo.desktop.overlay/target/

stderr: warning: failed to remove com.sap.hilo.desktop.overlay/target/

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1406)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1382)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1378)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1092)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1102)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:492)
at hudson.plugins.git.GitAPI.clean(GitAPI.java:253)
at hudson.plugins.git.extensions.impl.CleanCheckout.onCheckoutCompleted(CleanCheckout.java:28)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:908)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1254)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530)
at hudson.model.Run.execute(Run.java:1732)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)

=====================
=== manual Check ===
=====================
I have tryed to run the git command manually, and it seems to be the same problem :
C:\.jenkins\jobs\AR_VA_GerritVoter\workspace\gitRepo>git clean -fdx
Removing com.sap.hilo.desktop.overlay/target/
warning: failed to remove com.sap.hilo.desktop.overlay/target/

Note that /target folder is in .gitignore (for more than 1 month)

Since your problem directory is the "target" directory, I suspect that one or more programs are holding that directory, or a file in that directory open. Windows will not allow a file to be removed which is open by any process. Windows will not allow a directory to be removed which includes any open file.

One simple technique to test the theory is to stop the slave agent and restart it.

Another simple technique is to restart the slave computer.

The Windows file removal poliicy is much more challenging than the Unix file removal policy, so another alternative is to prefer Unix based build machines instead of Windows machines.

Thanks Mark,
I have tryed to run the job after a reboot => no old process holding the folder => same problem !
in batch mode (del /F/Q [...]\target , it fails => no error, but no delete!)

However I have investigated on the commit that generates the problem, and I have found a new file that generates a path greater than 255 characters in my target folder.
Could it be the root cause ?

I will check with the dev if he can change it and keep you in touch

I cannot switch on a unix machine (not owned by myself !)

Issue report needs to show that this is a problem with Jenkins. The Sysinternals tools (e.g. Process Explorer) could help determining which process is holding a file handle.

FWIW I've repeatedly had to remind my users to log out of the build server instead of just closing the RDC session – make sure there are no sessions with e.g. a cmd.exe in that directory open.

Sorry, didn't see the comment posted just before mine. It's likely that the long path is the problem in which case this is Not a Defect in Jenkins.

A few suggestions if you're right around ~260 chars and your developer is being stubborn:

• Use a short Jenkins (master/slave) root directory, e.g. D:\J
• Change the Workspace Root Directory on the master completely (Configure System; Advanced), e.g. D:\WS if building on the master
• Set the hudson.model.Slave.workspaceRoot system property to something shorter than workspace if building on a slave
• Set the hudson.matrix.MatrixConfiguration.useShortWorkspaceName system property to true for any Multi-configuration projects
• Configure a custom workspace in Advanced Project Options

Ok problem comes from the length of windows path > 255.
Problem is solved for us => should be a jenkins restriction

thanks Daniel,
I will check your proposition but we have some restrictions as some jobs are generated by an automate (=> to do in our side for the choice of folder names)