Where can I get some support for this issue? https://github.com/gradle/gradle/issues/28475 It seems like is making Gradle harder to use for users on Windows.

Which support do you envision, other than what is in that issue?

Hey Nicola, is your concern about errors like

"Immutable workspace contents have been modified" failure when workspace contents are not modified

or about errors like

java.io.UncheckedIOException: Could not move temporary workspace (C:\android\.gradle\8.7\dependencies-accessors\423f0288fa7dffe069445ffa4b72952b4629a15a-8a203d1d-3ff5-4f9d-ad38-d7188fa07baa) to immutable location (C:\android\.gradle\8.7\dependencies-accessors\423f0288fa7dffe069445ffa4b72952b4629a15a)

? I believe your question is about the latter since it's more common on Windows due to how file locking works. So I will answer for that issue: > What is the latest know version of Gradle that doesn't ship with the new execution model? It should be 8.5 > Ultimately, what is the reccomended workaround for users on Windows on Gradle 8.6+, Should we tell them to delete the caches, stop the daemons, or anything else? Deleting caching will not fix it, since this happens when cache is empty. Once cache has all entries populated there is no more issue. Restarting daemon could help. Normally the main issue is anti-virus or some other process that locks file from moving. > What's the expected ETA for this fix? We plan to address it in 8.12. Probably a fix will be to restore 8.5 logic for Windows

Hey @Anze Sodja thanks for the answer: Most of the users are reporting the latter error

Could not move temporary workspace

> What is the latest know version of Gradle that doesn’t ship with the new execution model?

It should be 8.5

Are you sure about this? Users on Gradle 8.6 are actually not reporting any issue. Most of the issues are coming from Gradle 8.8 and subsequent versions.

> Are you sure about this? Users on Gradle 8.6 are actually not reporting any issue. We introduced this execution in 8.6. It's possible that it got worse for some users in 8.8, since more logic uses it. But it happened already before. So what is basically the problem here: With < 8.5 we used file locking mechanism for some common caches so only one process could create some file/dir in common cache. With 8.6 we changed that to a "move semantic", since locking adds has some performance penalty. A result of some execution is then stored first in a temp folder and then on finish it's atomically moved to common cache. Now the problem on Windows is, that if some process uses this temporary dir/file, OS locks it and you can't move it. And such process is for example anti-virus that immediately tries to do something with such files. This block Gradle from using this move semantic.

It looks like the issue is that React Native sets the Gradle User home inside the project itself

Nope we don’t do that. We use the default Gradle User home

~/.gradle

I guess NodeJs watches whole project directory and thus interacts with Gradle cache files

I’m not 100% sure about this, but I suspect this could be culprit.

Nope we don’t do that. We use the default Gradle User home

~/.gradle

Then it must be some tutorial on the web that sets this up. I assumed that since the reporter in https://github.com/facebook/react-native/issues/46210 has the Gradle User Home in:

F:\tutorial-practice\frontend-development\react-native\native-cli-todo-app-2\android\.gradle\

Which looks like project dir. Also some others seems have it in project dir, e.g. reporter that figured NodeJS blocks Gradle from moving files in gradle/gradle#28475#issuecomment-2365330961 has it in

D:\src\AAAAA.ReactNative_01\apps\DemoApp2\android\.gradle

I assumed that since the reporter in https://github.com/facebook/react-native/issues/46210 has the Gradle User Home in:

I don’t think that’s the case. Most of the users are reporting the same exact problem and they’re all on Windows. I’ve never heard of users using a different user home. If you look at the issue on our end: https://github.com/facebook/react-native/issues/46210 The error message is always along the side of:

> java.io.UncheckedIOException: Could not move temporary workspace (F:\tutorial-practice\frontend-development\react-native\native-cli-todo-app-2\android\.gradle\8.8\dependencies-accessors\569c8b261a8a714d7731d5f568e0e5c05babae10-29ae1a11-17a6-474d-825c-7114fe1603d2) to immutable location (F:\tutorial-practice\frontend-development\react-native\native-cli-todo-app-2\android\.gradle\8.8\dependencies-accessors\569c8b261a8a714d7731d5f568e0e5c05babae10)

I’ve just create a fresh project on MacOS, and I also have that path in question:

android/.gradle/8.8/dependencies-accessors/569c8b261a8a714d7731d5f568e0e5c05babae10/

Yeah, this is project level cache then, my bad. I guess the culprint is still NodeJS inspecting this files and blocking Gradle

Ok I’ll try to investigate with some of our teams why this is happening. I suspect there might some globbing in place that starts from the root folder of the project and could block some of the files inside

android/.gradle

Still I haven’t 100% understood why this has broken from Gradle 8.6+

Still I haven’t 100% understood why this has broken from Gradle 8.6+

Because they introduced a new tactic where files are prepared in a temporary location and then are moved to their final location - iirc to reduce lock contention when multiple builds are run at the same time - but on Windows if any process - like Node.js or an AntiVirus - has a lock open on a file, it cannot be moved or deleted. On *nix systems you still can delete or move such files as only their hard-link is deleted but the process having the file open just has a reference to the actual inode of the file.

Amazing explanation @Vampire! Thank you very much for it

I also can’t reproduce it on my windows machine, which is also really confusing

To reproduce it you will have to delete

android/.gradle

(or at least

android\.gradle\<gradle-version>\dependencies-accessors

) so Gradle will try to re-create these files.

Amazing work @Anze Sodja! Thank you very much. Is this version available in a nightly release of Gradle that I can suggest folks to use as a workaround?

Yes, this change should be in the latest nightly (8.11-20240925002134+0000). And we plan 8.11-RC1 in two weeks if everything will go according to plan