Version control tracking information is not updated in the file explorer

[dan1994]

Details

• VSCode Version: 1.46.1
• Local OS Version: Windows 10 Home 2004 (Build 19041.329)
• Remote OS Version: Ubuntu 20.04
• Remote Extension/Connection Type: WSL

Steps to Reproduce

• Open a git tracked folder in VS code.
• Change the content of any file and save.
  (The sidebar doesn't show the file as modified)
• Reload VS code
  (Now the file appears as modified in the sidebar)
• Restore the original file contents
  (The file is still marked as modified until reload...)

Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: No

[neilenns]

I believe I'm seeing something similar to this with Remote - Containers. I keep getting lists of files showing as modified but they have no changes in them. If I re-open the folder locally the files show correctly as unmodified.

[bamurtaugh]

cc @aeschli Does it look like this issue relates to #2310?

[aeschli]

Could be #2310 . Is the file on a '/mnt/' share?

[dan1994]

Yeah, that's definitely it.
Was hoping to easily share my projects between Windows and WSL by putting them in the C: drive, and accessing them through /mnt/c.
I hope the other way around will work better (moving my projects to the WSL fs, and accessing from windows through \\wsl$\).

[dan1994]

Sadly, this seems to occur the other way around as well.
I've transferred all my projects into WSL, and now windows projects I'm working on that sit inside WSL don't have their tracking information updated when using the non-remote VS code.

[pergpau]

Exactly the same problem as dan1994 has. And restarting vsc shows the modifications.

My code files are in the linux file system (not mnt).

[pergpau]

I can add that it does work when using VSC WSL remote, but not when opening VSC from Windows.

[aeschli]

@pergpau No file events on on the Windows side on \\wsl$\.... That's microsoft/WSL#4739

Missing file events on the WSL side on /mnt/c, that's #3959.

Unfortunatly these are both WSL issues and there's currently nothing we can do in the Remote-WSL extension.