Recursive fs.watch crashes on Linux when deleting files

[maksis]

Version

v21.7.0

Platform

Linux ARCH-FS 6.7.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 03 Mar 2024 00:30:36 +0000 x86_64 GNU/Linux

Subsystem

fs

What steps will reproduce the bug?

Run the following code on Linux:

const fs = require('fs')

try {
  fs.mkdirSync('./parent/child', { recursive: true })
} catch (e) {
  console.error(e)
}

fs.writeFileSync('./parent/child/test.tmp', 'test')

fs.watch('./parent', { recursive: true }, (eventType, filename) => {
  console.log(eventType, filename)
})

fs.rmSync('./parent/child/test.tmp')

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior? Why is that the expected behavior?

Emit a watcher event

What do you see instead?

Error: ENOENT: no such file or directory, stat '/home/maksis/parent/child/test.tmp'
    at statSync (node:fs:1659:25)
    at FSWatcher.<anonymous> (node:internal/fs/recursive_watch:160:28)
    at FSWatcher.emit (node:events:519:28)
    at FSWatcher._handle.onchange (node:internal/fs/watchers:215:12) {

Additional information

No response

[phyreman]

I've been getting this same error when watching a /parent directory and deleting a subdirectory that contains files.

[kylo5aby]

I believe #51406 introduced this behavior, the FSWatch emit callback try to acquire the stat of the deleted file

node/lib/internal/fs/recursive_watch.js

Line 160 in 1264414

const currentStats = statSync(file);

can you take a look? @mcollina

[mcollina]

Here is the fix #52349

[joscarras]

I have just being hit with this bug as well for node 20. Was the fix merged? And if not, what version will this fix be included?

[domosapien]

@mcollina this is also a bug in v20.12, will this be backported to that or just for v22+?

[mcollina]

it should be backported