Error: "Process cannot access the file..."

This was logged here as bugs://84097 but I’m hitting a new element of the problem. If I delete the problematic folder (javax\inject\javax\inject), wait for the reference to resolve, and then build, then I can avoid the error. But if I have multiple references that need the resource then I get the error regardless during the build process.

For example, if I add firebase-analytics and firebase-crashlytics as references to my project, the error occurs every time because both libraries apparently need javax\inject.

Here’s a sample project. It is a clean slate project with the only changes being that I added firebase-analytics and firebase-crashlytics to the project. (30.4 KB)

Yeah, in that case only doing a command line build will work well. I’ll out prior’s on this issue — I basically need to find a Cocoa (or C) native unzip library. One option would be our own libGo, but that adds a lot of overhead… Actually, what I could do is see if I can do my own unzip “exe”, either using Go or the . NET library, and use that instead of /bin/unzip… I’ll have a look over the weekend.

To clarify, it’s failing from command line for me as well

Even after you cleaned the Gradle cache folder? Coz once those borked chips are extracted with missing access rights, everything will fail.

Ah, no, it looks like cleaning the gradle cache folder and then running from command line gets me a clean build. I thought I’d tried that but I guess not. Thanks

1 Like

Think I found a native unzip library I can use, so hopefully I can fix the underlying issue for next week’s build.

1 Like

Fixed for coming Friday’s build.

I’m still having an issue here when trying to run the build in Water. It (mostly) works for me from the command line, but I noticed that if I attempt to build one project from CLI and then cd to another project and build, I have to delete the problematic javax\inject folder again.

Here’s a test case. This one works for me from CLI but not Water. (31.2 KB)

That has to be a different issue then ,as the previous bug affected solely Fire, which used the macOS-native `unzips command tool.

I’ll have a look; but it’ll have nothing to do with what what was fixed before… :wink: