Resource Busy Or Locked Error

[irv075]

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.

[hi-ogawa]

Quick googling is suggesting that this might be because of some plugins not following Vite's convention:

• Error: EBUSY: resource busy or locked, lstat 'C:\hiberfil.sys' underfin/vite-plugin-vue2#24
• Plugin causes intermittent chokidar error in Vite watch mode on Windows windicss/vite-plugin-windicss#269

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?

[irv075]

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

[hi-ogawa]

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

[hi-ogawa]

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

[hi-ogawa]

@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?

[irv075]

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