La extracción y el reinicio de Git en Windows ocasionalmente muestran que los archivos aleatorios han cambiado

Question

A menudo, cuando hago un checkout de una rama diferente, o un reinicio, obtengo errores de 'permiso denegado' de una a una docena de archivos, pero el particular los archivos varían de ejecución a ejecución. Aquí está el resultado de una prueba que acabo de hacer, con GIT_TRACE = 1. El único rastro añadió la línea antes de que el mensaje de error:

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

Estoy bastante seguro de que esto es una carrera con un escáner de virus u otro servicio de indexación en mi máquina. Si la carrera persistiera, podría usar sysinternals para ver qué proceso tiene abierto el archivo. Sin embargo, sucede muy rápido, y no conozco una herramienta que me muestre este conflicto. Sorprendentemente, no he encontrado a nadie que describa un comportamiento similar. ¿Cómo detengo estos errores o diagnostico el problema más?

Estoy buscando específicamente finalizar la carrera de acceso al archivo identificando cualquier proceso que esté haciendo el acceso simultáneo. Así que las sugerencias para una herramienta que muestra qué proceso tiene un archivo bloqueado cuando se niega una edición sería muy útil. Conozco el 'desbloqueo' y herramientas similares que me mostrarán qué proceso mantiene un archivo bloqueado durante un período de tiempo. Esto no funciona para este problema, porque el proceso mantiene el archivo bloqueado durante un período muy corto. Entonces, la herramienta necesita recopilar los datos apropiados sin mi intervención, ya que soy demasiado lento.

Answer 1

desactivación de UAC virtualización parece haber fijado el problema.

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

Answer 2

Puede comenzar con un:

GIT_TRACE=1 

pero puede no mostrar mucho más que su mensaje original en relación con este archivo.

La causa habitual es algún editor abierto que quiera volver a cargar los archivos cuando se modifiquen, y que pueden entrar en conflicto con las manipulaciones de archivos de git.
Eso significa que la estrategia habitual es repetir el comando git después de tener cerca de tantas otras aplicaciones como sea posible. cualquiera

no he encontrado que describe un comportamiento similar

Ver this thread por ejemplo, ot this one, tanto en Cygwin.
¿Qué versión de Git está usando (Git en Cygwin, o msysgit, en una sesión de Cygwin o una sesión DOS?)

Answer 3

Usted podría intentar Filemon de elementos internos sys

Answer 4

Podría ser la búsqueda de Windows paso a paso, lo que intenta hacer archivos de índice a medida que se crean. Me encontré con este problema con svn checkout y tuve que excluir ese directorio de la indexación antes de poder realizar un proyecto completo.

Answer 5

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

No GIT relacionado!

El monitor de proceso de Sysinternals revela que el explorador de Windows interfiere con los archivos recién creados, quizás debido a algún complemento o qué, pero sucede.