AnkhSVN rompe permisos de uso compartido con ASP.NET 1.7 SVN

Question

El fondo (pase a la parte inferior si desea que la cuestión)

Recientemente he actualizado un repositorio SVN (alojado en assembla) a SVN 1.7. Después de hacerlo, comenzamos a encontrar intermitentemente muchos errores File Access Denied en las páginas del sitio ASP.NET que se encuentran en la copia de trabajo local del repositorio.

Algunas carpetas también comenzaron a obtener permisos de archivos extraños (se marcaron como de solo lectura) y se les quitó la función de compartir usuarios. Estos problemas solo comenzarían a ocurrir después de un ciclo de actualización/confirmación, a través del complemento Visual Studio de AnkhSVN, pero no todo el tiempo; parecía altamente temperamental.

La única solución temporal que hemos encontrado hasta ahora es la de confirmar los cambios pendientes, eliminar la copia local y volver a realizar una copia de trabajo completa (con TortoiseSVN). Sin embargo, esa no es una solución viable, y está afectando seriamente la productividad.

Este sitio es un WebWorkerRole de ASP.NET basado en Azure. Nunca ha dado problemas antes de la actualización a SVN 1.7. Intenté juguetear con los permisos internos de IIS para evitar el problema, sin embargo, no hay dados.

Mi Entorno

• Visual Studio 2010 Ultimate SP1 10.0.40219.1
• AnkhSVN 2.3.10509 (última versión, compatible con SVN 1.7.1)
• TortoiseSVN 1.7.1, Build 22161 - 64 Bit
• se ejecuta en modo de depuración a través del ambiente emulador Azure

La pregunta

¿Es posible que SVN 1.7 o cualquiera de las herramientas en mi entorno rompa los permisos de los archivos para que los archivos se vuelvan inutilizables en un sitio ASP.NET? y más importante, ¿cómo puedo arreglar esto?

---

El error exacto de permisos de ficheros objeto de dumping a cabo es la siguiente:

acceso a la ruta '// // archivo' denegado.

Descripción: Se produjo una excepción no controlada durante la ejecución de la solicitud web actual. Revise el seguimiento de la pila para obtener más información acerca del error y dónde se originó en el código.

Detalles de la excepción: System.UnauthorizedAccessException: El acceso a la ruta '// file //' está denegado.

ASP.NET no está autorizado para acceder al recurso solicitado. Considere concediendo derechos de acceso al recurso a la identidad de solicitud de ASP.NET identidad. ASP.NET tiene una identidad de proceso base (normalmente {MACHINE} \ ASPNET en IIS 5 o Servicio de red en IIS 6 e IIS 7, y la identidad del grupo de aplicaciones configurado en IIS 7.5) que se utiliza si la aplicación no se hace pasar por .Si la aplicación es suplantando a través de, la identidad será el usuario anónimo (generalmente IUSR_MACHINENAME) o el usuario de la solicitud autenticada .

Para otorgar acceso a ASP.NET a un archivo, haga clic con el botón derecho en el archivo en Explorer, seleccione "Propiedades" y seleccione la pestaña Seguridad. Haga clic en "Agregar" para agregar al usuario o grupo apropiado. Resalte la cuenta ASP.NET y marque las casillas para el acceso deseado.

Pero una copia de trabajo limpia no generará este error. Al comparar los permisos de los dos, parece que las copias de trabajo que no tienen errores se comparten (con IUSR y la cuenta local), mientras que las que se rompieron no se comparten, pero el usuario nunca cambia el uso compartido.

Answer 1

Lo resolví accediendo a la configuración de seguridad de la carpeta del sitio web y haciendo clic en Avanzado y luego Cambiar permisos para el usuario IIS_IUSRS. Revisé "Reemplazar todos los permisos de objetos secundarios con permisos heredables de este objeto" y hice clic en Aplicar.

Antes de eso, le había otorgado al usuario de IIS permisos completos para la carpeta tmp oculta en la raíz del proceso de finalización de la compra, pero no sé si esto ayuda con algo.

No estoy seguro de si esto es una solución permanente, pero en caso de que no lo sea, al menos puede usarlo para volver a aplicar los permisos para todos los archivos en una sola operación.

Answer 2

Cuando subversion actualiza un archivo, primero crea una versión temporal en .svn/tmp /. A continuación, mueve el archivo a la ubicación correcta. (Esto para evitar corrupciones)

En 1.6 hizo esto para cada directorio por sí mismo, pero en 1.7 hay solo un .svn en el directorio de nivel superior de su copia de trabajo.

Si de alguna manera los permisos del sistema de archivos de este directorio .svn están restringidos, es posible que las restricciones se copien con el archivo cuando se mueve en su lugar. (Subversion no cambia los permisos en sí mismo en Windows)

Answer 3

Mucha información se encuentra en carpetas .svn dentro del directorio donde se ejecutó el proyecto. Entonces, en mi opinión, es mejor usar SVN por separado de las herramientas de integración avanzadas. También this se ocupa de resolver un problema como este.

Answer 4

me encontré con este problema exactamente el mismo que sucedió cuando hice una 'Revert' usando:

• Tortoise SVN 1.6.16
• AnkhSVN 2.3.11269.1348.
• Visual Studio 2010 Professional
• Windows 7 - 64 bit.

Estaba completamente perplejo la primera vez que encontré el error de permisos y comencé pensando que era mi código. Después de un tiempo de juguetear, terminé borrando todo el proyecto y volviendo a descargar desde Subversion, que solucionó el problema.

Cuando volvió a ocurrir este problema, miré más de cerca el archivo revertido, y encontré que los permisos en los archivos revertidos no coinciden con los permisos de los otros archivos. Específicamente, los permisos de 'Usuarios' para la máquina en la que se está ejecutando Visual Studio faltan por completo.

Así que acaba de agregar en por:

• clic derecho sobre el archivo del problema. Esto hizo que apareciera la ventana de propiedades del archivo.
• Luego, hizo clic en 'Editar ...'. La ventana de permiso aparece.
• Luego, haga clic en Agregar y aparecerá la ventana 'Seleccionar usuarios, equipos, cuentas de servicio o grupos'.
• Haga clic en el botón Tipos de objetos y marque todas las casillas.
• Haga clic en el botón Ubicaciones y asegúrese de que el nombre de su máquina esté seleccionado.
• Escriba 'usuarios' y luego haga clic en el botón 'verificar nombres'.
• Haga clic en Aceptar en todas las ventanas para cerrarlas.

Su sitio web debería ejecutarse ahora sin el permiso de error.