Détails de la résolution de l’erreur de l’espace de travail temporaire de Gradle

click · 2025-08-08T11:24:02+09:00

Depuis Gradle 8.6, une erreur 'Could not move temporary workspace...' survenait fréquemment sous Windows, provoquant des échecs de build à cause d’un conflit avec les logiciels antivirus, mais elle est finalement corrigée dans Gradle 9.1 RC. Les utilisateurs Windows, qui subissaient ce problème de build depuis plus d’un an, pourront exécuter normalement les builds Gradle à partir de la version 9.1. (Issue associée : #31438) Fonctionnement des versions précédentes Verrouiller directement chaque fichier avec un file lock pour garantir l’immuabilité du cache de dépendances. Une approche simple et claire. Fonctionnement depuis la version 8.6 Pour améliorer les performances, CacheBasedImmutableWorkspaceProvider a été introduit, créant des fichiers temporaires basés sur des UUID, puis les déplaçant vers un chemin unique après le traitement. Cette méthode a été introduite pour résoudre les problèmes de baisse de performance du file lock lors des tests d’intégration. En environnement Windows, un conflit avec la surveillance en temps réel des antivirus (acquisition du lock lors de la création de nouveaux fichiers) a provoqué un échec du déplacement des fichiers temporaires. Correctif dans la version 9.1 Adoption d’une stratégie de verrouillage différenciée par système d’exploitation. En environnement Windows : adoption de LockingStrategy.WORKSPACE_LOCK. Cela crée un sous-répertoire (\workspace) dans le chemin du cache, acquiert un verrou sur l’ensemble de ce sous-répertoire et bloque ainsi les interférences fichier par fichier des programmes antivirus, ce qui règle le problème. Hors environnement Windows : conservation de l’ATOMIC_MOVE (version 8.6).

Depuis Gradle 8.6, une erreur 'Could not move temporary workspace...' survenait fréquemment sous Windows, provoquant des échecs de build à cause d’un conflit avec les logiciels antivirus, mais elle est finalement corrigée dans Gradle 9.1 RC.
Les utilisateurs Windows, qui subissaient ce problème de build depuis plus d’un an, pourront exécuter normalement les builds Gradle à partir de la version 9.1. (Issue associée : #31438)

Fonctionnement des versions précédentes

Verrouiller directement chaque fichier avec un file lock pour garantir l’immuabilité du cache de dépendances. Une approche simple et claire.

Fonctionnement depuis la version 8.6

Pour améliorer les performances, CacheBasedImmutableWorkspaceProvider a été introduit, créant des fichiers temporaires basés sur des UUID, puis les déplaçant vers un chemin unique après le traitement.
Cette méthode a été introduite pour résoudre les problèmes de baisse de performance du file lock lors des tests d’intégration.
En environnement Windows, un conflit avec la surveillance en temps réel des antivirus (acquisition du lock lors de la création de nouveaux fichiers) a provoqué un échec du déplacement des fichiers temporaires.

Correctif dans la version 9.1

Adoption d’une stratégie de verrouillage différenciée par système d’exploitation.
En environnement Windows : adoption de LockingStrategy.WORKSPACE_LOCK. Cela crée un sous-répertoire (\workspace) dans le chemin du cache, acquiert un verrou sur l’ensemble de ce sous-répertoire et bloque ainsi les interférences fichier par fichier des programmes antivirus, ce qui règle le problème.
Hors environnement Windows : conservation de l’ATOMIC_MOVE (version 8.6).

1 commentaires

click 2025-08-08

J'ai beaucoup galéré personnellement avec ça, alors j'ai écrit un article de blog après avoir vu que la PR avait été fusionnée. La section show est censée être un espace pour présenter directement les produits que j'ai développés, donc ce n'est probablement pas le format adapté ; je l'ai donc publiée comme actualité générale, mais je ne sais pas si c'est bien ça.