8

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.

Michael Donohue
  • 11,776
  • 5
  • 31
  • 44

5 Answers5

5

It might be the Windows Search Indexer, which tries do index files as they are created. I ran into this issue with svn checkout and had to exclude that directory from indexing before I could successfully checkout a full project.

mynameistechno
  • 3,526
  • 1
  • 37
  • 32
  • 2
    Switching off indexing for my repo folder fixed this issue for me. Windows Search Indexer is configured to index your Users folder by default, so if you have your repo stored in "My Documents" or similar, this could be the cause. Instructions for excluding directories: http://www.windowsnetworking.com/articles-tutorials/windows-7/Exploring-Windows-7s-New-Search-Features-Part2.html – Ross McNab Sep 19 '13 at 13:53
5

See my post https://connect.microsoft.com/VisualStudio/feedback/details/676699/cannot-open-linker-output-for-writing-or-cannot-close-file

Not git related!

Sysinternals' process monitor reveals that Windows explorer interferes with newly created files, perhaps due to some plugin or what, but it happens.

3

Disabling UAC Virtualization seems to have fixed the problem.

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

Michael Donohue
  • 11,776
  • 5
  • 31
  • 44
  • 1
    Note also comment #16 there. Putting your repo on a non-system partition also solves the problem. http://code.google.com/p/msysgit/issues/detail?id=320#c16 – Charles Roper Sep 12 '12 at 09:35
1

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
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    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 Aug 06 '09 at 19:16
  • 2
    @Michael: I understand. Sorry to have came up with the *exact* advice you didn't want to to follow ;) – VonC Aug 06 '09 at 19:53
0

You could try Filemon from sys internals

Tim Abell
  • 11,186
  • 8
  • 79
  • 110