Linux: unable to watch a symbolic link folder

[bpasero]

Using watcher@2.0.0-alpha.11 on Ubuntu 20. Steps:

• create a symbolic link pointing to a folder: ln -s <linked-folder-path> <folder-path>
• install watcher on that symbolic link

Error: inotify_add_watch failed: Not a directory

Other watcher liks nsfw are not running into that problem it seems.

[devongovett]

Perhaps we should call realpath on the watcher root before starting watching?

[bpasero]

One thing VS Code does when it comes to file watching is to check whether the path to be watched is a symbolic link or not because it looks like on macOS using fs-events, you can pass a symbolic link to the native watch function, but you end up with the target of the link when it comes to the events (at least nsfw and chokidar behave like that). As such, we rewrite the events back to the original form to ensure the paths match with what the user has opened.

In other words, imagine:

• user opens ~/path/linked-folder in VS Code
• we ask the file watcher to watch on ~/path/linked-folder
• we expect file events to begin with ~/path/linked-folder because all listeners in VS Code compare the currently opened workspace to the paths from the events
• as such we figure out the target of the link and then rewrite the events to match the original form

For any watcher I would probably never expect the watcher to fail when I give it a symbolic link. The interesting question is whether you would expect the returned events to be in the form of the resolved link target or the original form. If you use the resolved link target, any upstream user needs to be aware of that. This is fine for VS Code given we already have that code, but maybe unexpected for others.

Source pointers: https://github.com/microsoft/vscode/blob/5991e3c4b97eca5568069bf3e0910ab693ad3549/src/vs/platform/files/node/watcher/nsfw/nsfwWatcherService.ts#L246-L270

[bpasero]

Not a big deal anymore for VS Code usage at least. We realpath the folder to watch and that seems to work fine: https://github.com/microsoft/vscode/blob/c8b4380937e5e3d0be24ab89cb757c304bd1ce72/src/vs/platform/files/node/watcher/parcel/parcelWatcherService.ts#L219

[bpasero]

I think to be consistent with other platforms:

• realpath the path that is passed in for watching (though you will probably also have to massage the paths back to its original form when sending paths back to the client)
• ignore symbolic links when recursively attaching file watchers in children of the path

The latter is quite important because neither macOS nor Windows automatically watch symbolic links within the path to watch. A related issue in VS Code (microsoft/vscode#121854) results in high CPU on WSL (Linux) because a symbolic link is followed automatically for file watching and that can be a very expensive operation.

If a client wants to watch a symbolic link, expect the client to pass in that path for watching and don't do it automatically.

[bpasero]

I think the current behaviour after all the changes for Linux is pretty fine now.