Package resolve race condition? Sharing (EBUSY) violations detected [RESOLVED]

On one of my projects I’ve been having problems resolving packages after wiping the project’s Library directory. Here is a portion of my editor log showing some of the errors on startup:

An error occurred while resolving packages:
One or more packages could not be added to the local file system:

com.unity.addressables: EBUSY: resource busy or locked, open ‘C:\Users\Foo\UnityProjects\Test\Library\PackageCache.tmp67923xclRTGVqo8k\copy\Runtime\AssetReferenceUIRestriction.cs’

com.unity.burst: EBUSY: resource busy or locked, open ‘C:\Users\Foo\UnityProjects\Test\Library\PackageCache.tmp679276j9S0D0KK63\copy\Editor\LongTextArea.cs’

com.unity.collections: EBUSY: resource busy or locked, open ‘C:\Users\Foo\UnityProjects\Test\Library\PackageCache.tmp6792pIQ73gG6UB1K\copy\Unity.Collections\BitField.cs’

Each time I attempt to load the project, I get similar errors but with different files involved.

As you can see, the package manager is complaining that it cannot write files because there is a sharing (EBUSY) violation. Because my project’s manifest contains numerous projects, each of which indirectly references some of the same com.unity.* packages, I suspect the package manager may be trying to copy multiple copies of a file into the project’s package cache at the same time.

I have been able to resolve this issue by manually copying packages from Unity’s AppData package cache into my project’s package cache, but that’s obviously not a workable long-term solution, and I can’t ask other members of my team to do this every time this problem occurs.

I’m using Unity 2020.2.4 on Windows.

I just discovered another thread about a similar issue. Other people who had this problem said they were using Visual Studio Code when it happened. I, too, had VS code opened on my project’s root directory. When I closed VSCode, the problem appears to have gone away.

So VSCode must be creating short locks on new files as they get created.

3 Likes