Git checkout et réinitialiser sur Windows montre parfois des fichiers aléatoires ont changé

Question

Souvent quand je fais un checkout d'une branche différente, ou une réinitialisation, j'obtiendrai des erreurs «permission refusée» de Windows pour un à une douzaine de fichiers - mais le particulier les fichiers varient d'une exécution à l'autre. Voici la sortie d'un test que je viens de faire, avec GIT_TRACE = 1. La seule trace a ajouté une ligne avant que le message d'erreur:

 
$ 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" 

Je suis assez sûr que ce soit une course avec un scanner de virus ou tout autre service d'indexation sur ma machine. Si la course persistait, je pourrais utiliser sysinternals pour voir quel processus a ouvert le handle de fichier. Cependant, cela arrive très vite, et je ne suis pas au courant d'un outil qui me montrera ce conflit. Étonnamment, je n'ai trouvé personne décrivant un comportement similaire. Comment faire pour que ces erreurs s'arrêtent, ou diagnostiquer le problème plus loin?

Je cherche spécifiquement à mettre fin à la course d'accès aux fichiers en identifiant tout processus faisant l'accès simultané. Donc, des suggestions pour un outil qui montre quel processus a un fichier verrouillé lorsqu'une modification est refusée serait très utile. Je suis conscient de 'unlocker' et des outils similaires qui me montreront quel processus détient un fichier verrouillé pendant une période de temps. Cela ne fonctionne pas pour ce problème, car le processus conserve le fichier verrouillé pendant une période très courte. L'outil doit donc collecter les données appropriées sans mon intervention, car je suis trop lent.

Answer 1

Désactivation UAC La virtualisation semble avoir fixé le problème.

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

Answer 2

Vous pouvez commencer par un:

GIT_TRACE=1 

Mais il peut ne pas afficher beaucoup plus que votre message d'origine en ce qui concerne ce dossier.

La cause habituelle est un éditeur ouvert qui veut recharger les fichiers lorsqu'il est modifié, et qui peut entrer en conflit avec les manipulations de fichiers de git.
Cela signifie: la stratégie habituelle est de répéter votre commande git après ayant près autant d'autres applications que vous pouvez.

Je n'ai pas trouvé quelqu'un qui décrit un comportement similaire

Voir this thread par exemple, ot this one, tant sur Cygwin.
Quelle version de Git vous utilisez (Git sur Cygwin, ou msysGit, dans une session Cygwin ou une session Dos?)

Answer 3

Vous pouvez essayer Filemon de sys internes

Answer 4

Il pourrait être Windows Search Indexer, qui essaie faire des fichiers d'index comme ils sont créés. Je suis tombé sur ce problème avec svn checkout et j'ai dû exclure ce répertoire de l'indexation avant de pouvoir récupérer un projet complet.

Answer 5

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

git Non lié!

Le moniteur de processus de Sysinternals révèle que Windows Explorer interfère avec les fichiers nouvellement créés, peut-être en raison de certains plugins ou quoi, mais cela arrive.