-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temporary workspace cannot be moved to immutable location when files left open on Windows #27844
Comments
I am also seeing this exception on project builds, not just syncs. Here's a sample end-of build on a large project with build failing due to a syntax error. Exception is logged AFTER the build failure messages are logged.
|
Thank you for providing a valid report. The issue is in the backlog of the relevant team and is prioritized by them. |
Thanks for the report! Do you have something special about your setup wrt file systems? Is your Gradle user home in some unusual location? I'm adding some more logging around this problem. I'll post a snapshot Gradle version here in a bit, could you try reproducing this problem with it? If you could publish the project itself on GitHub, that'd be great, too, though I think the issue is more likely related to your environment than to the code. |
Hi, I have experienced id, as far as I know my setup is nothing different. I am not sure if I can reproduce it a sit only happens initially. Calling "--dry-run" than Reload Gradle Project seems to have fixed it. |
I've published the ./gradle wrapper --gradle-version 8.6-branch-lptr_execution_fix_immutable_workspace_error-20240129122519+0000 It would be great to capture a stack trace (using |
I have updated to version 8.6-branch-lptr_execution_fix_immutable_workspace_error-20240129122519+0000 and run sync and built the app without any issues |
Could you try with a different user home? (Or just delete your |
I have reverted back to rc3 Hopefully others with same issue will test and confirm too |
Hm... 🤔 I did not change anything in the way things work, only how much we log about them, so any issue you bumped into in 8.6-rc-3 should still exist in this snapshot version. These are all the changes: #27851 |
I can reproduce the same problem using Gradle 8.6-RC-2 with IntelliJ Ultimate using Windows 10 inside an enterprise environment: IntelliJ IDEA 2023.3.3 (Ultimate Edition) Runtime version: 17.0.9+7-b1087.11 amd64 Gradle 8.6-rc-2Build time: 2024-01-12 14:49:03 UTC Kotlin: 1.9.20 For some strange reasons I did work with 8.6-rc-2 after I added the Gradle Enterprise plugin to create a build scan for this issue... I will try to use the published version for addional logging. |
@hfhbd could you try with |
@lptr Yes, this was the plan :) |
Sorry, just now saw you already said so :) Thanks for trying, really appreciated! |
Not sure if I am missing anything. Just to be sure, I have deleted .gradle folder under user account. |
Thanks @NLLAPPS. Just so I understand correctly: previously you were able to reproduce with 8.6-rc-3 multiple times, and now after cleaning Can you maybe try to run a build at the same time as a sync in AS is happening? My best bet is that something goes wrong when there's a race condition, even though I don't see how. The code is written specifically to handle race conditions like that... |
No, only once and only when (I believe) when attempting download gradle for the first time.
Correct. I was unable to reproduce it.
I'll give it a go. |
Not sure if it make a difference but I have |
OK, I think I figured it out. Here’s the problem: an artifact transform writes some files in the temporary directory, but leaks some file handles, i.e. it does not close them properly. On Unixes this is no problem, as you can move (or even delete) inodes just fine even while they are kept open. But Windows just doesn’t allow that. So it will throw an |
The fix should be relatively simple, too. If we see an |
I'm just catching up on the above. If you still need more info/runs etc. lemme know, but the last comments make it sounds like you found it :-). Unfortunately the projects I've encountered this on are not on github, and one is quite large, so sharing them is a problem. But I have time over the next day or two if there is something helpful I can provide using 8.6-branch-lptr_execution_fix_immutable_workspace_error-20240129122519+0000. |
We are running Gradle 8.6 and this issue still occurs, at least on macOS. Even deleting the files in question won't help:
Axing the entire |
Similar issue on Windows 10. It often happens after adding new dependency to libs.versions.toml.
|
@saschpe It appears that you are experiencing a different issue with Gradle 8.6. Can you please raise a separate issue report? |
@saschpe, @LukasVykuka this is tracked in #28475. In Gradle 8.7 the problem is not causing the build to fail anymore: #28503. |
same issue for 8.6 |
Same issue Windows 10 |
Downgrading
in Worked for me |
same issue for 8.7 Windows 10 |
I had to install the latest version of Android Studio, switch to 8.5, let Android Studio do a build of something, then switch to 8.6, start the emulator through Android Studio, and then it just worked |
If it helps, in my react-native project, I solved the problem by deleting the android/build directory and running gradlew cleanBuild `For more on this, please refer to https://docs.gradle.org/8.6/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation. BUILD SUCCESSFUL in 4m 56s` |
@ductridev could you give some more information about your use case? There should be no failure with Gradle 8.7 anymore.
|
A build operation failed. how to fix it please help |
I think the problem is from Gradle whose version is 8.6 |
The current default version react-native is using is 8.6, just change it to 8.5 or 8.7, and then it will build successfully without any errors. |
The same problem happens on Linux when building with Gradle 8.8 and AGP 8.4.1. |
Current Behavior
See google issue for more details, which google is looking at (I believe). Sync attempts on various projects that worked fine under Gradle 8.5 are failing using 8.6 RCx with this exception, which is being thrown by class
org.gradle.internal.execution.steps.AssignImmutableWorkspaceStep
which appears to be an internal Gradle exception. I can find no comments or Gradle doc that describe this exception or how to resolve it. Android Studio Jellyfish is now requiring gradle 8.6.rc-1 or later, and this exception has been seen in both Gradle 8.6 rc-1 and rc-3. Wanted to document this issue here in case it is a Gradle 8.6 issue before 8.6 goes production,As indicated in the google issue doc, in many cases just retrying the sync works, as long as a new gradle daemon is not started between the error and the sync retry. Which seems unusual to me :-)
Expected Behavior
Even if this exception is caused by some error in AGP and not Gradle 8.6, it seems like there should be doc or comments in the code or something that indicate possible causes of this Gradle exception, and even possible remedies. If this is a new bug in 8.6, then of course more than a doc change is required.
Any info/feedback on this would be appreciated by me, and maybe by whoever at Google the above issue is assigned to :-)
Context (optional)
It can be avoided by not using 8.6, which means not using Android Studio Jellyfish. It can (at least in some cases) be worked around in Jellyfish and 8.6-rc-3 by doing additional sync retries until the sync completes without this exception. It is affecting project syncs on every project with which I have tried to use Android Studio Jellyfish.
Steps to Reproduce
See google issue
Gradle version
8.6 RC3
Build scan URL (optional)
No response
Your Environment (optional)
Android Studio Jellyfish Canary 5 using AGP 8.4.0-alpha05 running on Windows 11.
The text was updated successfully, but these errors were encountered: