[Win] Deleting folder results in EPERM error that locks all folders that are recursively watched

[Faline10]

The Issue:
[Windows only] Chokidar (and fs.watch under the hood) throws an EPERM error when a child folder of a folder that is being watched recursively is deleted.
According to notes i saw on another bug, the Chokidar code here is supposed to deal with it:

chokidar/lib/nodefs-handler.js

Lines 89 to 99 in f17186d

	watcher.on('error', function(error) {
	// Workaround for https://github.com/joyent/node/issues/4337
	if (process.platform === 'win32' && error.code === 'EPERM') {
	fs.open(path, 'r', function(err, fd) {
	if (fd) fs.close(fd);
	if (!err) broadcastErr(error);
	});
	} else {
	broadcastErr(error);
	}
	});

In fact, the comments even lead to this old underlying bug in node:
nodejs/node-v0.x-archive#4337 "Deleting a watched folder in Windows ALWAYS rise an [Error: watch EPERM]"
I'm not sure what these lines are supposed to do to address this bug though. It seems to be just broadcasting the error, as long as the file exists.

Now it would be one thing if I could ignore this error and everything would continue to work. In fact, the watchers do continue to work, receiving the unlinkDir event and others. However, a recursive watcher will then lock all child folders, and any file system operation (delete, rename, etc) on them will fail due to EPERM, whether the operation is through node or the windows file system GUI. This issue doesn't seem to occur with non-recursive watchers, perhaps because the underlying node issue is to throw that error for the top level folder being watched. I'm not sure if Chokidar is creating many watchers for child folders under the hood, but if it is, that would make sense with this old bug.

Turning on the option to suppress EPERM errors from within Chokidar does not stop it from locking up afterwards.

Shutting down the watcher after the EPERM error gets rid of the lock. However, restarting causes it to come back(!).

It doesn't seem to be possible to stop the EPERM error from occurring in the first place using Chokidar or fs.watch, as far as I know. Though perhaps NSFW would be an alternative library that doesn't rely on fs.watch.

Device:
Windows 10 Pro, 64bit

Example code:

const watcher = chokidar.watch(path, {
  persistent: true,
  ignoreInitial: true,
  cwd: path
});

// insert business logic on events

watcher.on('error', error => {
  logger.log(error)
  if (error.code === 'EPERM' && Config.WINDOWS) {
    // recursive watcher causes a lock on all watched folders on Windows after EPERM error, so could close it here
    // ...but restarting it causes the locking issue to come back, so that's not the solution
  }
});

I'm aware that the EPERM fs.watch errors are out of Chokidar's hands. However, I'm surprised that the resulting locking issue occurs. Any thoughts on solutions or, for the meantime, workarounds for the locking issue?

[Faline10]

Update: We switched from using Chokidar to Node Sentinel File Watcher (https://www.gitkraken.com/nsfw). As a native library, it avoids Windows EPERM errors and the locking issues that resulted. I'm not closing this bug, though, since this is still a major issue with Chokidar.

[sant123]

See #566 (comment)

[paulmillr]

Update to Chokidar v3, it should resolve this.

[iniatse]

it is not solved in v3...

[paulmillr]

Let's move to #566