Resource Busy Or Locked Error
irv075 opened this issue · comments
Describe the bug
The extension throws a resource busy or locked
exception intermittently. It seems to be trying to access files in the root of the C drive - usually c:\DumpStack.log.tmp
or c:\hiberfil.sys
(if dumpstack logging has been disabled).
After the error has been thrown I have to disable then re-enable the extension to get it running again - it will then fail again after an amount of time ranging from a few seconds to 15 minutes.
OS: Windows 10
VS Code:1.88.1
Vitest Extension: 0.8.6
Reproduction
No special reproduction required, the exception is thrown even when no tests are being ran, just having the extension enabled for a period of time.
Output
[INFO 10:26:05 AM] [v0.8.6] Vitest extension is activated because Vitest is installed or there is a Vite/Vitest config file in the workspace.
[INFO 10:26:06 AM] [API] Running Vitest: v1.5.0 (vitest.config.ts)
[INFO 10:26:06 AM] [API] Starting Vitest process with Node.js: C:\Program Files\nodejs\node.EXE
[INFO 10:26:09 AM] [API] Vitest process 454476 created
[INFO 10:26:29 AM] [API] Vitest process 454476 closed successfully
[INFO 10:26:29 AM] [API] Running Vitest: v1.5.0 (vitest.config.ts)
[INFO 10:26:29 AM] [API] Starting Vitest process with Node.js: C:\Program Files\nodejs\node.EXE
[INFO 10:26:31 AM] [API] Vitest process 521280 created
[Worker] node:events:496
throw er; // Unhandled 'error' event
^
Error: EBUSY: resource busy or locked, lstat 'C:\hiberfil.sys'
Emitted 'error' event on FSWatcher instance at:
at FSWatcher._handleError (file:///C:/Repositories/testapp/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:46060:10)
at NodeFsHandler._boundHandleError (file:///C:/Repositories/testapp/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:44533:43)
at ReaddirpStream.emit (node:events:518:28)
at emitErrorNT (node:internal/streams/destroy:169:8)
at emitErrorCloseNT (node:internal/streams/destroy:128:3)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
errno: -4082,
code: 'EBUSY',
syscall: 'lstat',
path: 'C:\\hiberfil.sys'
}
Node.js v20.11.0
Version
0.8.6
Validations
- Check that you are using the latest version of the extension
- Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
- Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
- The provided reproduction is a minimal reproducible example of the bug.
Quick googling is suggesting that this might be because of some plugins not following Vite's convention:
Can you check if you have any plugins which might be doing something similar?
Also, can you check if you can reproduce with vitest
cli without vscode extension?
Apologies for the delay in replying.
I am not using any additional plugins for vitest, and only the React plugin for vite. The issue does seem to be reproduced when using vitest cli:
✓ src/pages/requests/requests.test.tsx (16 tests) 939ms
Test Files 1 passed (1)
Tests 16 passed (16)
Start at 12:25:56
Duration 9.94s
PASS Waiting for file changes...
press h to show help, press q to quit
node:events:496
throw er; // Unhandled 'error' event
^
Error: EBUSY: resource busy or locked, lstat 'C:\hiberfil.sys'
Emitted 'error' event on FSWatcher instance at:
at FSWatcher._handleError (file:///C:/Repositories/testapp/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:46060:10)
at NodeFsHandler._boundHandleError (file:///C:/Repositories/testapp/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:44533:43)
at ReaddirpStream.emit (node:events:518:28)
at emitErrorNT (node:internal/streams/destroy:169:8)
at emitErrorCloseNT (node:internal/streams/destroy:128:3)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
errno: -4082,
code: 'EBUSY',
syscall: 'lstat',
path: 'C:\\hiberfil.sys'
}
Node.js v20.11.0
only the React plugin for vite
Interesting. Actually official react plugin is also doing /@react-refresh
https://github.com/vitejs/vite-plugin-react/blob/814ed8043d321f4b4679a9f4a781d1ed14f185e4/packages/plugin-react/src/fast-refresh.ts#L5, so that's might be the culprit.
The issue does seem to be reproduced when using vitest cli
Thanks for confirming. For now, I'll move this issue to Vitest repo, but I this it's also possible that the same issue can happen on Vite cli too. If that's the case, we need to report that to either Vite or React plugin https://github.com/vitejs/vite-plugin-react
Btw, can you provide "System Info" in a comment? You can simply run npx envinfo --system --npmPackages '{vitest,@vitest/*,vite,@vitejs/*}' --binaries --browsers
like we have on issue template https://github.com/vitest-dev/vitest/issues/new?assignees=&labels=pending+triage&projects=&template=bug_report.yml
@patak-dev It looks like the issue of /@react-refresh
not following \0
convention is brought up in vitejs/vite#15299. Does Vite team have any plan to change it in the future?
Btw, can you provide "System Info" in a comment? You can simply run
npx envinfo --system --npmPackages '{vitest,@vitest/*,vite,@vitejs/*}' --binaries --browsers
like we have on issue template https://github.com/vitest-dev/vitest/issues/new?assignees=&labels=pending+triage&projects=&template=bug_report.yml
System:
OS: Windows 10 10.0.19045
CPU: (12) x64 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
Memory: 15.24 GB / 31.64 GB
Binaries:
Node: 20.11.0 - C:\Program Files\nodejs\node.EXE
npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: Chromium (120.0.2210.144)
Internet Explorer: 11.0.19041.3636
npmPackages:
@vitejs/plugin-react: 4.2.1 => 4.2.1
@vitest/coverage-v8: ^1.5.0 => 1.5.0
@vitest/ui: ^1.5.0 => 1.5.0
vite: ^5.2.10 => 5.2.10
vitest: ^1.5.0 => 1.5.0