Running the dev tools on Windows causes Vite to fail due to watching /

[birjj]

Build tool

Vite

Where do you see the problem?

• [ ] In the browser
• [x] In the terminal

Describe the bug

When running the dev server with the Vite plugin, I occassionally encounter the following error, causing the dev server to throw an error and fail:

Error: EBUSY: resource busy or locked, lstat 'C:\DumpStack.log.tmp'

This crashes the dev server, requiring me to manually run it again.

The most peculiar part of this is that Vite is watching C:\ at all.

---

After some digging with breakpoints I can conclude:

The error occurs when rollup attempts to access the file C:\DumpStack.log.tmp while it is locked by another process. This is more-or-less intended behavior. The problem is that rollup watches C:\DumpStack.log.tmp at all - it is entirely unrelated to the project.

The problem happens because chokidar watches the directory a file is in (and since vite uses rollup, and rollup uses chokidar, this extends to vite itself).
As @crxjs/vite-plugin is using virtual files named /crx-*, this means that chokidar is told to watch the / directory, causing issues on Windows.

Reproduction

None currently available. Running npm run dev on the default setup should be enough, although it might take some time for the error to happen (as it requires some other process to lock a file in the root directory just as chokidar tries to stat it).

You can test if the issue is still happening by, even on Linux machines, by following these steps:

1. Add a conditional breakpoint to this location (compiled into node_modules/rollup/dist/shared/index.js#4000) with the expression paths_ === "/"
2. Run vite in debug mode. In vscode this is done by going to "Run and Debug", clicking "JavaScript Debug Terminal", and running npm run dev in that terminal.
3. If vite starts watching the root directory, the conditional breakpoint will trigger.

Logs

node:events:505
      throw er; // Unhandled 'error' event
      ^

Error: EBUSY: resource busy or locked, lstat 'C:\DumpStack.log.tmp'
Emitted 'error' event on FSWatcher instance at:
    at FSWatcher._handleError (C:\Users\...\dev\extension\node_modules\rollup\dist\shared\index.js:4239:10)
    at ReaddirpStream.NodeFsHandler$1._boundHandleError (C:\Users\...\dev\extension\node_modules\rollup\dist\shared\index.js:2715:43)
    at ReaddirpStream.emit (node:events:527:28)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -4082,
  code: 'EBUSY',
  syscall: 'lstat',
  path: 'C:\\DumpStack.log.tmp'
}

System Info

System:
    OS: Windows 10 10.0.19044
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    Memory: 17.34 GB / 31.73 GB
  Binaries:
    Node: 16.15.1 - C:\Program Files\nodejs\node.EXE
    npm: 8.11.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 106.0.5249.119
    Edge: Spartan (44.19041.1266.0), Chromium (106.0.1370.47)
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    @crxjs/vite-plugin: ^1.0.9 => 1.0.12
    vite: ^2.9.9 => 2.9.10

Severity

annoyance

[rahulbansal16]

@birjj This is occurring for me. Do you have any workaround for it?

[Chieffo2021]

@rahulbansal16 My temporary workaround is moving the project from dir C:\myproject to D:\myproject. Usually, there is no DumpStack.log.tmp file that will cause the error.

But the root problem also needs to be solved.

[birjj]

@rahulbansal16 As mentioned by @Chieffo2021, moving the project to a different drive would be a workaround (as / would then refer to that drive's root location, which likely doesn't have any files that are being locked).

Another workaround might be to disable dumpstack logging entirely, by setting the following registry value:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]
"EnableLogFile" = dword:00000000

After doing so (and restarting your computer) you can delete the DumpStack.log.tmp file, which should fix the immediate issue. Note that the problem might still occur with other files that happen to be locked while chokidar is trying to stat them.

[hansifer]

To add to @birjj's excellent analysis, I ended up addressing this by patching node_modules/rollup/dist source directly, adding an additional constraint (something like !error.path.startsWith('C:\\')) to the guard in FSWatcher's _handleError() method (in my case in es/shared/watch.js) to suppress the error emit.

Obvious limitations with this approach but given the relatively high frequency of crash vs low frequency of dependency update it's worth it in my case.

[rezasohrabi]

Hi everyone,

I'm working with the CRX package and I've run into this issue where certain files seem to be locked, leading to an EBUSY error and crashes dev server.

Has anyone experienced this issue with the CRX package or have any insights into what might be causing this error by using CRX?

[Toumash]

Hi everyone,

I'm working with the CRX package and I've run into this issue where certain files seem to be locked, leading to an EBUSY error and crashes dev server.

Has anyone experienced this issue with the CRX package or have any insights into what might be causing this error by using CRX?

I didnt have this problem since switching to the beta release in ~december 2022 (which is not a beta btw)