Regression (Linux): FileSystemWatcher.onDidCreate doesn't fire event when watched file is a symlink

[karrtikr]

Does this issue occur when all extensions are disabled?: Yes

Version: 1.63.2 (user setup)
OS: Ubuntu

Steps to Reproduce:

1. Open a workspace folder in extension host while debugging your extension .
2. Use the following code in your extension.

const globPatern = new RelativePattern(vscode.workspace.workspaceFolders[0].uri.fsPath, '*/bin/python');
const fsWatcher = this.workspaceService.createFileSystemWatcher(globPatern);
fsWatcher.onDidCreate((e) => {
    console.log('Old code create', e.fsPath);
});

3. Use command python3 -m virtualenv .virtualenv to create a virtual environment. Notice Old code create... is not printed.

[bpasero]

We no longer automatically follow symbolic links for file watching for performance reasons. See https://code.visualstudio.com/updates/v1_61#_file-watching-changes

[karrtikr]

I understand that symlinks (link's path) won't be followed, but does this mean symlink files themselves cannot be watched for changes? For eg. in this case we just wanted to look for the python file (symlink), and not follow the symlink (for changes in link's path).

[karrtikr]

If symlink file type are indeed no longer supported, unfortunately workaround mentioned to use files.watcherInclude doesn't work for us, as that would mean we have to configure this setting explicitly for all our users. Will it possible to configure supporting symlinks via the API itself?

[bpasero]

Extensions are now actually able to provide default settings, so maybe that is an option? See https://code.visualstudio.com/updates/v1_63#_configuration-defaults-overrides

Let me reopen this issue and treat it as feature request, I think maybe given the new file watching support for out-of-workspace folders (see https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_64.md#vscodeworkspacecreatefilesystemwatcher-now-supports-any-path) we could argue that an explicitly watched in-workspace path will be checked for being a symlink or not and then supported.

[karrtikr]

Thanks, just to clarify, we want to be able to monitor symlink creation. This is crucial for us as Python environments across all platforms contain such symlinks and detection logic won't work otherwise. Without this we won't be able to use the VSCode file watcher in the Python extension even though we really want to, and will have to keep relying on other libraries as we have been doing.

Extensions are now actually able to provide default settings, so maybe that is an option? See https://code.visualstudio.com/updates/v1_63#_configuration-defaults-overrides

That does bring us closer but paths to watch can be dynamic and depends on discovery logic, so specifying a set of fixed paths in package.json does not always work for us.

[bpasero]

Hm, ok then maybe I misunderstood. To my knowledge, the creation of a symlink should actually be reported as a file change event, though you would not receive any file events for changes to the target of that link.

To clarify: you are only interested in a symlink getting created or deleted but do not require the watcher to follow the symlink and watch for changes on the target?

[karrtikr]

Yes that's correct.

To my knowledge, the creation of a symlink should actually be reported as a file change event, though you would not receive any file events for changes to the target of that link.

Not sure if it's important but I was using WSL.

[bpasero]

Not sure if it's important but I was using WSL.

It is important, for WSL specifically we switch to a polling only solution because file events are not reliable. @aeschli has the details when we do that, I think it depends on WSL1 vs WSL2 usage.

Can you try to reproduce without WSL?

[aeschli]

To have polling in WSL, you need to be in a WSL1 distro and have set the setting "remote.WSL.fileWatcher.polling": true (it's off by default). The WSL log (Remote-WSL: Show Log) would contain some message about polling.

[bpasero]

I cannot reproduce, either with our polling file watcher or with the normal one. Steps:

• Linux Ubuntu
• open a folder in VSCode
• from a terminal create symlink via ln -s <source> <target>
• observer how the link appears in explorer

Works for me both with a file link and a folder link.

[bpasero]

Could be a WSL only problem that only appears inside WSL and then this should be a bug report for the WSL team.