views:

467

answers:

3

Often when I do a checkout of a different branch, or a reset, I will get 'permission denied' errors from windows for one to a dozen files - but the particular files vary from run to run. Here's the output from a test I just did, with GIT_TRACE=1. The trace only added the one line before the error message:

$ git checkout master
trace: built-in: git 'checkout' 'master'
error: git checkout-index: unable to create file dotnet/src/myfile.cs (Permission denied)
D       dotnet/src/myfile.cs
Switched to branch "master"

I'm pretty sure this is some race with a virus scanner or other indexing service on my machine. If the race persisted, I could use sysinternals to see what process has the file handle open. However, it happens very quickly, and I'm not aware of a tool that will show me this conflict. Surprisingly, I haven't found anyone describing similar behavior. How do I make these errors stop, or diagnose the problem further?

I'm specifically looking to end the file access race by identifying whatever process is doing the simultaneous access. So suggestions for a tool that shows which process has a file locked when an edit is denied would be very helpful. I'm aware of 'unlocker' and similar tools which will show me what process holds a file locked for a period of time. This doesn't work for this issue, because the process keeps the file locked for a very short period. So the tool needs to collect the appropriate data without my intervention, as I'm too slow.

+1  A: 

You can begin with a:

 GIT_TRACE=1

But it may not display much more than your original message regarding this file.

The usual cause is some opened editor which wants to reload the files when changed, and that can conflict with git's file manipulations.
That means: the usual strategy is to repeat your git command after having close as many other applications as you can.

I haven't found anyone describing similar behavior

See this thread for instance, ot this one, both on Cygwin.
What version of Git are you using (Git on Cygwin, or MSysGit, in a Cygwin session or a Dos session?)

VonC
The reason I ask this question is to avoid the superstitious actions that may or may not help me, and actually figure out the cause of my problem. So "the usual strategy is to repeat your git command after having close as many other applications as you can." is exactly what I don't want to do.
Michael Donohue
@Michael: I understand. Sorry to have came up with the *exact* advice you didn't want to to follow ;)
VonC
A: 

You could try Filemon from sys internals

Tim Abell
+1  A: 

Disabling UAC Virtualization seems to have fixed the problem.

See http://code.google.com/p/msysgit/issues/detail?id=320

Michael Donohue