- Seit Gradle 8.6 kann es unter Windows durch einen Konflikt mit Antivirenprogrammen häufig zu Build-Fehlern mit „Could not move temporary workspace…“ kommen; in Gradle 9.1 RC ist dieses Problem nun behoben.
- Windows-Nutzer:innen können den rund ein Jahr andauernden Build-Fehler nun ab Version 9.1 voraussichtlich wieder normal mit Gradle bauen. (related issue: #31438)
Funktionsweise in früheren Versionen
- Es wurde direkt ein Dateilock auf die Datei selbst gelegt, um die Unveränderlichkeit des Dependency-Caches sicherzustellen. Ein einfacher und klarer Ansatz.
Funktionsweise ab Version 8.6
- Zur Leistungsverbesserung wurde
CacheBasedImmutableWorkspaceProvidereingeführt, wodurch temporäre Dateien anhand von UUIDs erstellt und nach der Verarbeitung in einen eindeutigen Pfad verschoben werden. - Dieses Verfahren wurde eingeführt, um das Performance-Problem der Dateisperren bei Integrationstests zu beseitigen.
- In Windows-Umgebungen kam es zu einem Konflikt mit der Echtzeitüberwachung von Antivirenprogrammen (Sperrung beim Anlegen neuer Dateien), wodurch das Verschieben temporärer Dateien scheiterte.
Patch-Ansatz in Version 9.1
- Es wird eine betriebsystemabhängige Sperrstrategie eingeführt.
- Windows: Die Strategie LockingStrategy.WORKSPACE_LOCK wurde übernommen. Dabei wird im Cache-Pfad ein Unterverzeichnis (\workspace) angelegt, und für dieses gesamte Unterverzeichnis wird ein Lock gesetzt, wodurch Eingriffe einzelner Dateien durch Antivirenprogramme blockiert und das Problem gelöst wird.
- Nicht-Windows-Umgebungen: die bestehende ATOMIC_MOVE-Lösung aus der 8.6-Version wird beibehalten.
1 Kommentare
Ich habe einen Blogartikel geschrieben, weil ich selbst sehr darunter gelitten habe, als das PR gemerged wurde. Da die Rubrik „show“ hauptsächlich dazu dient, ein eigenes Produkt vorzustellen, wirkte sie dafür nicht passend, daher habe ich es als allgemeine News eingetragen; ich bin mir aber nicht sicher, ob das korrekt ist.