It is not clear based on the bug report if you're using the git command line implementation or if you're using the jgit implementation in your project definition. Can you clarify which you are using?

When I use Git plugin 2.0 and git client plugin 1.4.4 and I restrict the job to only run on windows and I add "Wipe out repository & force clone" as an additional action in the git configuration for that job, the first execution of the job succeeds, then all subsequent executions fail with a report that one of the pack files in the git repository is held open by another process and cannot be deleted.

The steps I used to define that failing job:

0 - Configure jgit as an available git implementation in the global configuration
1 - Create a new Jenkins job (I named mine jgit-windows)
2 - Configure the Jenkins job to use Git for SCM
3 - Enter https://github.com/MarkEWaite/check_git.git as the Git URL
4 - Switch from the git command line to jgit as the git executable
4 - Add "Checkout to specific local branch" to the branch master-local as part of the git configuration
5 - Restrict the job to only run on Windows
6 - Add "Wipe out repository & force clone" as part of the git configuration
7 - Save the job

Once the job has been saved, run it twice. The first run will succeed, the second run will fail with a report that pack file is busy

I think the simplest work around is to not wipe the workspace, but only clean the workspace. The clean should work because it does not depend on removing the pack file that some portion of either jgit or the git plugin has left the file open.

We have the same problem and it is a major pain point for our testing because lot os testruns are getting aborted. So far we haven't really figured out what's going on but as it looks like only Windows 8 and 8.1 are affected. Any Windows version lower than that is fine.

Also the problem only seems to start when one of those machines are getting restarted. It could be because of an update or a system config change like changing a hostname. Once the restart has been finished and you reconnect the machine to the cluster, the next testruns for it will fail.

We are using Jenkins 1.509.x (LTS).

The failure itself for us varies but looks like:

00:00:17.878 Deleting project workspace... Cannot delete workspace: java.nio.file.FileSystemException: c:\jenkins\workspace\ondemand_functional\mozmill-env\python\Lib\lib2to3\tests\data\fixers\myfixes_init_.py: The process cannot access the file because it is being used by another process.

Can you describe the use case where you need to wipe the workspace rather than just clean it?

It seems like a clean would meet most use cases and would avoid this bug, without requiring a bug fix.

I don't want to have to do both of them. Why am I forced to manually clean the workspace after I restarted on of the machines? If something is necessary Jenkins should handle that. Similar as when I disconnect the slave, and reconnect it again.