EBUSY on Windows GitHub Action

[mcollina]

Last pnpm version that worked:

7.29.0

pnpm version:

7.29.1

Code to reproduce the issue:

Run Github Actions on a large workspace project on Windows

Expected behavior:

Install not failing

Actual behavior:

Take a look at https://github.com/platformatic/platformatic/actions/runs/4375185250/jobs/7656654747

---

It seems that somewhere a retry for EBUSY is missing.

[mcollina]

It seems this is not fixed after all. Even after updating to v7.29.2 I can still see the error:

https://github.com/platformatic/platformatic/actions/runs/4415116019/jobs/7737726392
https://github.com/platformatic/platformatic/actions/runs/4415116019/jobs/7737726392#step:5:49

pnpm: EBUSY: resource busy or locked, copyfile 'D:\.pnpm-store\v3\files\88\77dc18bb5f6272f93b7010441d2315f4423f844c872c2233ef6869962e5fba2eabd82a26f8efda839127957951731ccb593454ef26716548ed95cf0caf519d' -> 'D:\a\platformatic\platformatic\node_modules\.pnpm\@swagger-api+apidom-parser-adapter-asyncapi-yaml-2@0.69.0\node_modules\@swagger-api\_tmp_3312_1eaceeb08df46e12cb0cdc51434afc6b\cjs\adapter.cjs'
Progress: resolved 1780, reused 1638, downloaded 0, added 1635
Progress: resolved 1780, reused 16[51](https://github.com/platformatic/platformatic/actions/runs/4415116019/jobs/7737726392#step:5:52), downloaded 0, added 1646

[zkochan]

I thought graceful-fs retries on EBUSY

[mcollina]

Apparently not, which sounds weird.

https://github.com/search?q=repo%3Aisaacs%2Fnode-graceful-fs+EBUSY&type=code

[mcollina]

I can consistently reproduce this on my virtualized windows environment, not just in Github Actions. If you have a fix to test I can definitely test pre-release.

[zkochan]

ok, I'll check on Windows too. Maybe I'll be able to reproduce it locally.

[zkochan]

Try 7.30.0-0

[mcollina]

I cannot reproduce this locally anymore. Thanks for the help/support!

[Aliziloubaf]

Falling back to copying packages from store
Falling back to copying packages from store
Falling back to copying packages from store
Falling back to copying packages from store
Falling back to copying packages from store
Falling back to copying packages from store
Falling back to copying packages from store
Falling back to copying packages from store
Falling back to copying packages from store
 EBUSY  EBUSY: resource busy or locked, copyfile 'd:\pools.pnpm-store\v3\files\91\9eded09712882972a3e568d465b89a5a1c12c81122a9f6052a47bb6d8b15127f864a0fe2246cd2ec402ae44c913751280ce297156ba41e45a75f8ddaabef4e' -> 'C:\xxx\node_modules.pnpm@swagger-api+apidom-core@0.69.0\node_modules@swagger-api_tmp_2716_bc7f600b996c76bc14cfcb02f9f226e1\cjs\index.cjs'

pnpm: EBUSY: resource busy or locked, copyfile 'd:\pools.pnpm-store\v3\files\91\9eded09712882972a3e568d465b89a5a1c12c81122a9f6052a47bb6d8b15127f864a0fe2246cd2ec402ae44c913751280ce297156ba41e45a75f8ddaabef4e' -> 'C:\xxx\node_modules.pnpm@swagger-api+apidom-core@0.69.0\node_modules@swagger-api_tmp_2716_bc7f600b996c76bc14cfcb02f9f226e1\cjs\index.cjs'
Progress: resolved 886, reused 861, downloaded 3, added 799

C:\xxx>pnpm --version
7.30.0

The Problem exists after installing pnpm 7.30.0

[Aliziloubaf]

package.zip

unzip the file, and copy the package.json file in an empty directory and call
pnpm install

and in our case we get above Error. We are sure that virus scanner check that file but your retry does not work

[zkochan]

Try to use a store from the C: drive. You can control the store location with the store-dir setting.

[Aliziloubaf]

Hallo zkochan, i did set store-dir to c:\pools.pnpm-store and the same Result

[Aliziloubaf]

[Aliziloubaf]

can you please open the issue. Thanks

[mcollina]

@Aliziloubaf something that is too much of a coincidence is that we both get this error as part of the @swagger-api package.

[Aliziloubaf]

Is there any solution for this Problem?

[zkochan]

I cannot reproduce the issue locally on my PC. I think the only solution to try to reproduce it would be to add platformatic as an e2e test to pnpm.

However, I am not sure how to fix this if retry did not help.

[mcollina]

I cannot reproduce the problem anymore locally, only on actions. For some very unknown reasons some files are locked for 30+ seconds.

I think the best way to solve this it to provide a recipe on how to have your action retry automatically.

[zkochan]

Maybe we could try to read the file and then write it?

[mcollina]

I think that would be the last resort option, but it could be worth a shot.

I'm starting to think there is some bug in actions.

[zkochan]

Actually, it looks like graceful-fs added a retry only for the rename function, so it makes sense that the issue wasn't fixed: isaacs/node-graceful-fs@ab32dab

If I understand correctly, to fix this, we'd have to add EBUSY to this if statement:

https://github.com/isaacs/node-graceful-fs/blob/234379906b7d2f4c9cfeb412d2516f42b0fb4953/graceful-fs.js#LL182C2-L182C2

[zkochan]

I have patched graceful-fs and released pnpm v7.31.0-0

@mcollina and @Aliziloubaf, please try it.

I still can't reproduce it even via CI.

[geekact]

@zkochan Had you try to install package swagger-ui which can reproduce the error always.

[zkochan]

I have added dependencies from platformatic and they don't fail: #6340

[geekact]

Well, I have been encountering it for a very long time in my repository https://github.com/aomex/aomex/actions/runs/4606117155/jobs/8139017700

[zkochan]

Does v7.31.0-0 fix the issue?

[geekact]

Does v7.31.0-0 fix the issue?

@zkochan I tested my project with v7.31.0-0 several times, and CI looks fine.

[mcollina]

This seems to be fixed for me.

[zkochan]

@mcollina do you mean with v7.31.0-0 it is fixed?

[mcollina]

I can still see this in v8.1.1: https://github.com/platformatic/platformatic/actions/runs/4616647923/jobs/8161974544?pr=848#step:5:187.

Not sure why it's so intermittent.

[Herr-Sepp]

Unfortunately, the bug also occurred with us.
Both with 7.31 and with 8.1.1

Caused by dependencies of swagger-ui
@swagger-api+apidom-parser-adapter-api-design...

I can exclude access from an anti-virus.
It is pnpm that tries to recreate the file even though it still has an open handle on the file itself.

As you can see pnpm.exe tries to create the file twice and the second attempt is rejected. (SHARING VIOLATION)

I hope this helps to isolate the bug

[zkochan]

The fix was not released in 7.31.0 or 8.1.1

The fix is only in v7.31.0-0

[Herr-Sepp]

Yes the version v7.31.0-0 works.
Sorry I just read over the zero at the end.

However, the cause still seems to be there.
pnpm will now simply try to create the file a second time later, when the first handle ist closed. Which is a good workaround, thanks for that.
For me these files are affected:

pnpm\@swagger-api+apidom-parser-adapter-api-design-systems-json@0.69.2\node_modules\@swagger-api\_tmp_12384_b4c04ea93e3303812d69707345268c61\cjs\adapter.cjs
pnpm\@swagger-api+apidom-parser-adapter-api-design-systems-yaml@0.69.2\node_modules\@swagger-api\_tmp_12384_336fdb4d578da6406948c138ee16790a\cjs\adapter.cjs
pnpm\@swagger-api+apidom-parser-adapter-asyncapi-json-2@0.69.2\node_modules\@swagger-api\_tmp_12384_902676b2cdf249cd44dde05abde81b59\cjs\adapter.cjs
pnpm\@swagger-api+apidom-parser-adapter-asyncapi-yaml-2@0.69.2\node_modules\@swagger-api\_tmp_12384_73a2379256cc9449bfc2aa1c8dcc6fcc\cjs\adapter.cjs
pnpm\@swagger-api+apidom-parser-adapter-openapi-json-3-1@0.69.2\node_modules\@swagger-api\_tmp_12384_f89bd39ab26e0e1d0bc8ed0191bdac53\cjs\adapter.cjs
pnpm\@swagger-api+apidom-parser-adapter-openapi-yaml-3-0@0.69.2\node_modules\@swagger-api\_tmp_12384_56df7cbdfff1c7dbf31235c278c4c1bc\cjs\adapter.cjs

[zkochan]

🚢 7.32 and 8.2