Linux: deleting watched folder does not reestablish watching after re-create

[bpasero]

I tested on Windows, macOS and Linux how the watcher behaves when the path to be watched is being deleted and found that macOS and Windows can deal with this well: when the folder is being restored, watching continues to work (at least from my basic testing that is what I figured).

But on Linux there is a delete event when the path is being deleted but the watching does not pick up again when restoring the folder.

[devongovett]

Hmm, I guess we'd have to start watching the parent folder when the root dir is deleted to see if it's re-created? Do other watchers handle this on Linux?

[devongovett]

Actually, seems like this causes a crash on Windows currently. I fixed that in #69. But it does not watch again after creating the deleted directory again, same as Linux. I'm leaning toward making this consistent on macOS as well since it seems that's the only one that handles this. Callers of the watcher can detect this case and subscribe to notifications from the parent directory if they need notifications about the directory being re-created.

[bpasero]

From my testing with nsfw I figured out that macOS is capable of continuing to work even when you delete the watched folder. In fact, fs-events seems to report deletes all the way up the parent chain and can deal with the folder being restored. I believe the reason for this is that fs-events is a global OS service that is always active, i.e. you are not subscribing to a specific file handle but to a global service that emits events. These events are there, independent whether someone is watching or not. For nsfw specifically I opened Axosoft/nsfw#148 to remove their handling when the root path is deleted. Their solution is to stat the root each loop which I found not such an ideal solution.

Btw macOS also has a kFSEventStreamCreateFlagWatchRoot flag, but I never understood why you need it, given deletes are reported for me even when not using that flag. I believe you only need it if you want to distinguish normal events from kFSEventStreamEventFlagRootChanged.

On Windows: in my testing I was not really able to delete the root that is watched with ReadDirectoryChangesW. I think when you watch a folder, the folder handle is "in use" and as such you cannot delete the folder - it is locked. Maybe there is a setting for this to change that, but I think so far for VS Code at least, users were never able to delete the workspace they had opened due to that.

And on Linux, from my testing:

• nsfw does not report a delete event when removing the watched path but is capable of restoring the watching once the folder comes back
• chokidar reports all the deletes, but does not restore the watching

Maybe worthwhile checking what nsfw is doing specifically on Linux: https://github.com/Axosoft/nsfw/tree/master/src/linux

If parcel-watcher decides to consistently deal with this on all platforms then it would be good if some kind of signal could be sent back to the user that a path is removed and watching stopped. That allows to install the watcher again when the path comes back. VS Code actually has code for that purpose for nsfw: https://github.com/microsoft/vscode/blob/a4342f3addc29f405a5cb4aab359b0b98223411e/src/vs/platform/files/node/watcher/nsfw/nsfwWatcherService.ts#L343

[devongovett]

Sorry, didn't mean to close this. I think after #69 it is consistent across platforms. Do you think looking for a delete event on the watched root is enough for you to know when to establish a watch on the parent directory to look for it to be recreated if needed?

[bpasero]

@devongovett yeah a delete event on all platforms for the root is perfect 👍 . We already have code to reestablish watching on the root when it goes away, we just need that event from parcel watcher.

[devongovett]

In that case, I really can close this! 😀

[bpasero]

@devongovett just to clarify, is parcel emitting the delete event when the root path is deleted on all platforms already today or does that require a new release?

[bpasero]

Oh nice, I just verified it works on macOS and Linux and requires the changes in here from your PR to work on Windows. I will prepare my branch to be ready for that 👍