Skip to content
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

[BUG] - "EBUSY: resource busy or locked" when importing code #1535

Open
Dullstar opened this issue Nov 8, 2024 · 4 comments
Open

[BUG] - "EBUSY: resource busy or locked" when importing code #1535

Dullstar opened this issue Nov 8, 2024 · 4 comments
Labels
bug Minor issue

Comments

@Dullstar
Copy link

Dullstar commented Nov 8, 2024

Attempting to import a code (regardless of new profile/update existing profile) can sometimes cause an EBUSY error. The path appears to be a temporary file that is only used for importing codes and is deleted by the time the user sees the error message. There is some, but not full consistency to which mod will cause the issue; my current working hypothesis is that the mods aren't always processed in the same order so the mod shown in the error will be whichever one gets processed first.
The following code is an example of a code for Lethal Company that was affected: 01930992-3fb0-9787-bcd4-3d09cdbe4839

It doesn't seem to affect all players, but I believe some of the players may be using Thunderstore and since the issue affects importing codes, the person generating the code is not affected, so I don't know 100% if anyone else tried to import it using r2modman specifically (at least I am told the codes are compatible with both).

I did not notice any obvious evidence of another program attempting to access the file and the issue persisted after a restart. Clearing r2modman-related files from AppData does not seem to fix the issue.

It only happens when importing a code, but I don't know what predicts if a code will be affected (though a mod that fails in one code appears to have an increased likelihood of failing in another code -- I do not know if it will occur on all codes that contain an affected mod). If a new code that has had the offending mods removed is obtained, the affected mods can successfully be downloaded after the import is complete.

Because the mods can be manually downloaded, it would probably at least help if there was the option to import as much of the code as possible and then manually fix the mods that fail due to this error.

Best guess: is there some sort of data race happening during the import process?

Screenshots
image

@Dullstar Dullstar added the bug Minor issue label Nov 8, 2024
@Dullstar Dullstar changed the title [BUG] - EBUSY: resource busy or locked [BUG] - "EBUSY: resource busy or locked" when importing code Nov 8, 2024
@Yuki-iso
Copy link

Hey, having the same issue!
Trying to import a code (or file) that was generated from Thundestore will result in this EBUSY error.
Looking it over, mods that cause this error seem to be mods that are disabled, but not deleted...
Removing the disabled mod from the profile entirely, and re-importing it from code should work?
I had a friend remove 1 mod, which caused it to break on the next mod... But due to the giant list of disabled mods in the affect pack meant that it was easier to download Thunderstore at that point :( (which did work)

@Inkiai
Copy link

Inkiai commented Nov 16, 2024

Me and my friend get the exact same issue with our old profile, we tried several times in different ways and no luck. Only manually downloading mods worked unfortunately :(

@Copper-Bot
Copy link

Hi,
Same issue here, at least for Lethal Company
A workaround that seems to work is to use r2modman version 3.1.49
(For Windows, take "r2modman-3.1.49.exe", not the setup one, or else it will automatically upgrade to the latest r2modman version)

Since version 3.1.50, I can't get the mods to import correctly from a code (also generated from Thunderstore).
A friend had to downgrade to r2modman 3.1.49 as well to import the code correctly.

@Dullstar
Copy link
Author

I'd have to test more codes to be confident 3.1.49 is unaffected, but so far it does appear that the issue was introduced in 3.1.50.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Minor issue
Projects
None yet
Development

No branches or pull requests

4 participants