- Desde Gradle 8.6, en entornos Windows, el error 'Could not move temporary workspace...' comenzó a ocurrir por un conflicto con programas antivirus, provocando fallos de build con frecuencia, pero finalmente se solucionó en Gradle 9.1 RC.
- Los usuarios de Windows saldrán del problema de compilación que llevaban sufriendo por más de un año y podrán ejecutar builds de Gradle con normalidad a partir de la versión 9.1. (Issue relacionada: #31438)
Comportamiento en versiones anteriores
- Garantizaba la inmutabilidad de la caché de dependencias aplicando un bloqueo de archivo (file lock) directamente sobre el archivo. Un enfoque simple y claro.
Comportamiento desde la versión 8.6
- Se introdujo
CacheBasedImmutableWorkspaceProvider para mejorar el rendimiento, generando archivos temporales basados en UUID y moviéndolos a una ruta única al finalizar el trabajo.
- Este enfoque se implementó para resolver la caída de rendimiento del bloqueo de archivos durante las pruebas de integración.
- En entornos Windows, este cambio entró en conflicto con la vigilancia en tiempo real de programas antivirus (adquisición de bloqueos cuando se crean archivos nuevos), provocando fallos al mover los archivos temporales.
Método de parcheo en la versión 9.1
- Se adoptó una estrategia de bloqueo diferenciada por sistema operativo.
- En Windows: se eligió la estrategia LockingStrategy.WORKSPACE_LOCK. Esto crea un subdirectorio (\workspace) dentro de la ruta de caché y adquiere un lock sobre todo el subdirectorio, evitando la interferencia individual de archivos del antivirus y resolviendo así el problema.
- En entornos distintos de Windows: se mantiene ATOMIC_MOVE (método de la versión 8.6).
Aún no hay comentarios.