Windows: file-watcher notification repeats on file open with a roaming UNC home
- Dominant language
- TypeScript
- Stars
- 193k
- Forks
- 42.4k
- PR merge metrics
- PR metrics pending
Description
On Windows with the home folder on a roaming UNC path, opening each file triggers a file-watcher error notification. The expected behavior is to report an ongoing watcher failure once and continue detecting external file changes where supported.
Does this issue occur when all extensions are disabled?: Yes. I verified this with ZERO extensions installed.
- VS Code Version: 1.32 and 1.33 (I verified the problem on both; exact patch versions still to be added).
- OS Version: Windows; build not yet provided.
- Exact notification and watcher error: Not yet captured.
### Steps to reproduce
1. Use Windows with the home folder redirected to a UNC share, such as `\\server\profiles\user`.
2. Open several files successively in VS Code.
3. A watcher error notification appears for each opened file.
I verified this on both versions with zero extensions installed. I still need to add whether the opened files are local or on the share, and inside or outside an open workspace.
### Current-source findings (not yet verified against affected versions)
Reviewed commit `814ab138a8994ee8984c0acd6816ad77e2aa3cef`. This is current-source analysis, not analysis of the reported 1.32/1.33 releases; the watcher implementation and notification behavior must be traced in those versions before attributing the cause:
- [EditorService.handleVisibleEditorsChange](https://github.com/microsoft/vscode/blob/814ab138a8994ee8984c0acd6816ad77e2aa3cef/src/vs/workbench/services/editor/browser/editorService.ts#L199) installs a watcher for each newly visible file outside the workspace. [NodeJSFileWatcherLibrary](https://github.com/microsoft/vscode/blob/814ab138a8994ee8984c0acd6816ad77e2aa3cef/src/vs/platform/files/node/watcher/nodejs/nodejsWatcherLib.ts#L197) calls `fs.watch(realPath)` and reports native watcher failures.
- The existing [polling recovery](https://github.com/microsoft/vscode/blob/814ab138a8994ee8984c0acd6816ad77e2aa3cef/src/vs/platform/files/node/watcher/baseWatcher.ts#L186) detects a missing path reappearing; it does not report edits to an existing file whose native watcher failed.
- [WorkspaceWatcher.onDidWatchError](https://github.com/microsoft/vscode/blob/814ab138a8994ee8984c0acd6816ad77e2aa3cef/src/vs/workbench/contrib/files/browser/workspaceWatcher.ts#L73) notifies for ENOSPC/EUNKNOWN. EUNKNOWN is already marked SILENT in this revision, and ordinary Node watcher errors without those markers do not trigger this notification branch.
These findings identify relevant code, but do not establish the cause of the reported popup. The zero-installed-extensions reproduction rules out a dependency on a user-installed extension. The exact error and analysis of the affected releases are still needed to identify the failing watcher.
### Proposed resolution
If native watching fails for an existing UNC file, provide a bounded `fs.watchFile` fallback in the shared non-recursive watcher layer that reports edits, deletion, and recreation and stops on disposal. The current reappearance-only recovery does not provide that behavior. Keep healthy native watches and UNC access restrictions unchanged.
Coalesce notifications for the same ongoing failure while retaining diagnostic logs. The current-source UNC access checks should not be assumed to exist in the reported historical releases.
### Validation
I reproduced this on VS Code 1.32 and 1.33 with zero extensions installed. I haven't implemented or tested a fix. The code analysis above is based on source inspection. The exact notification, File Watcher trace output, Windows build, and affected-release source analysis remain outstanding. A regression check for the proposed fallback should cover external edits, deletion/recreation, and disposal after closing the editor, followed by verification on a redirected-home Windows setup.
Related UNC reports: #137361 and #152537. Neither establishes a duplicate of this roaming-home symptom.
Contributor guide
Assessment
This issue has not been assessed yet.