Source Control fails to track real-time changes on non-system drives (Windows/Linux) since v1.109.5 #299373
Description
Does this issue occur when all extensions are disabled?: Yes
- VS Code Version: 1.109.5
- OS Version: Windows 11 / Linux (Dual Boot/Cross-platform)
Steps to Reproduce:
- Launch VS Code with extensions disabled: code --disable-extensions.
- Open a Git repository located on a secondary drive or partition (e.g., D:\project on Windows).
- Modify an existing file or create a new one and save it.
- Actual Result: The Source Control view fails to detect the change in real-time. No "Untracked" or "Modified" status appears in the sidebar.
- Observation: Running Developer: Reload Window forces an initial scan that correctly identifies the changes, but subsequent edits are again ignored by the real-time watcher.
Description:
The Git Source Control integration in version 1.109.5 is failing to track file system events on non-system drives. Based on the internal Git logs, there is a clear failure in the GitFileSystemProvider when attempting to resolve virtual URIs for files on secondary drives.
Git Output Logs:
The logs show that VS Code detects a potential change but fails to stat or read the file through the Git provider:
2026-03-05 11:18:46.460 [info] > git ls-files --stage -- x.py [35ms]
2026-03-05 11:18:46.460 [warning] [GitFileSystemProvider][stat] File not found - git:/d%3A/path/to/x.py.git?%7B%22path%22%3A%22d%3A%5C%5Cpath%5C%5Cx.py%22...%7D
2026-03-05 11:18:46.461 [warning] [GitFileSystemProvider][readFile] File not found - git:/d%3A/path/to/x.py.git...
Additional Context:
- This appears to be a regression in v1.109.5.
- It specifically affects absolute paths on secondary drives (e.g., Drive D:).
- The URI mapping (git:/d%3A/...) seems to be failing to map back to the physical disk correctly during real-time observation.