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

[Ratstail91]

Describe the bug

The following error occurs regularly every 2-10 minutes on my machine - it's happened almost consistently for over a year now, and it's driving me nuts, because I have to reboot webpack. I don't use chokidar directly, but one of my dependencies do.

[watch:client] node:events:368
[watch:client]       throw er; // Unhandled 'error' event
[watch:client]       ^
[watch:client]
[watch:client] Error: EBUSY: resource busy or locked, lstat 'C:\DumpStack.log.tmp'
[watch:client] Emitted 'error' event on FSWatcher instance at:
[watch:client]     at FSWatcher._handleError (C:\Users\kayne\Desktop\core-server\node_modules\chokidar\index.js:647:10)
[watch:client]     at ReaddirpStream.NodeFsHandler._boundHandleError (C:\Users\kayne\Desktop\core-server\node_modules\chokidar\lib\nodefs-handler.js:303:43)
[watch:client]     at ReaddirpStream.emit (node:events:390:28)
[watch:client]     at emitErrorNT (node:internal/streams/destroy:157:8)
[watch:client]     at emitErrorCloseNT (node:internal/streams/destroy:122:3)
[watch:client]     at processTicksAndRejections (node:internal/process/task_queues:83:21) {
[watch:client]   errno: -4082,
[watch:client]   code: 'EBUSY',
[watch:client]   syscall: 'lstat',
[watch:client]   path: 'C:\\DumpStack.log.tmp'
[watch:client] }

Versions (please complete the following information):

• Chokidar version 3.5.3
• Node version v16.13.1
• OS version: Windows 10, via cygwin

To Reproduce:

I think if you get this project up and running entirely on windows, webpack will crash eventually:

https://github.com/krgamestudios/MERN-template

Expected behavior
No crashes.

Additional context
I don't use chokidar directly, but my dependencies do (webpack-dev-server, nodemon).

Nodemon uses version 3.5.2.

[paulmillr]

I need the exact code that reproduces the crash. Otherwise, any part of your stack could cause this. Webpack could cause this. We don't fix webpack issues.

Also, the "file" could be actually locked for writing / reading.

[Ratstail91]

The file doesn't exist, but I did get crashes with that MERN-template after all.

I've tried updating everything, even my node version, but the crash still happens - I'm totally lost as to what to do about it.

Edit: I just realized it has to be nodemon's usage, since the crash never happens in production.

[rhtpandeyIN]

Make sure the listening directory/file exists in your system, this error usually occurs when chokidar is trying to listen to a directory which don't exist in the system. Maybe a case of production vs local env directory structure.

[mklueh]

I'm facing the same issue on Windows 11, even with the latest version 4.0.1 when using Nuxt or Wxt mainly (both based on Vite).

[43081j]

@paulmillr maybe we should explicitly handle EBUSY statuses? Either retry the stat or ignore the failure?

Difficult without a reproduction though

[mklueh]

@43081j I don't know how to reproduce that. I dont even have a vite config anywhere.

My setup is an Nx workspace with some Nuxt and Wxt apps.

But I've looked around on Github searching for this issue and I'm certainly not the only one affected.

crxjs/chrome-extension-tools#538

vitest-dev/vitest#5740

nuxt-community/auth-module#1795

But I'm wondering, what is even happening in this error case.

Is the FileWatcher trying to access 'C:\DumpStack.log.tmp' and then crashes, because another process is accessing it? Could this be related to Windows Defender?

[43081j]

interestingly, every occurrence of this in the wild seems to be DumpStack.log.tmp, which I'm pretty sure nobody is intentionally watching (and I doubt anyone is watching C:/)

so we definitely have some funky stuff going on here.

the error is being emitted by readdirp, which itself is just emitting the error node gave us (but that could've originated from our own destroy(err) calls I think)

it smells like a node windows thing that isn't playing nice with us, rather than anything to do with our file watching

[Ratstail91]

Hey, I know I opened this, but I've moved on from this project, and I never found the cause.

I can say that this problem disappeared after I convered my project to Docker. I know it's not a solution for everyone, but it's there.

I'm gonna unfollow this issue, but you can @ me if you need more info. Good luck!