Window (11) WSL2 file changes in IDE/git only visbibly after fetch

[amkdev]

Hey guys I'm trying to setup the following enviroment:

Ubuntu 20.04 LTS in WSL2
repo / files are stored in WSL2 (for better lando/webpack performance)

I'm editing the files in Windows, Atom as IDE ... I also tried VS Code ... same problem.

The problem:

If I change a file in the repo this isn't recognized by the IDE / Git.
I have to fetch - than I see all the unstaged changes / changed files.

I searched the web for hours. But I found only two similar problems but the solutions didn't help.

Why Windows (or the IDEs) doesn't check the file state in the file system of the WSL2?

For ideas or help I would be very grateful.

[PhilipOakley]

Could this be a File System Monitor (FSmonitor) problem, in that you (your Git) may have the expectation that the appropriate FSmonitor is running, but isn't really (WSL2 (*nix) vs Windows monitors), so some other command has to cause (your fetch) the update of the file status?

I think there are some discussions on the Git list, or perhaps in a 'closed' issue (i.e retry the issue search but remove the is:open filter ! )

[dscho]

FSMonitor is automatically disabled on network shares (in this context, \\wsl$\<distro-name> qualifies for a network share). So: no, it cannot be FSMonitor.

[amkdev]

Thanks for you answer. I found out that the file commication between WSL and Windows is quiet an issue. I found a discussion, where they talked about problems with webpack file watching from or to WSL. This doesn't worked at all. It is also necessary to take into account that the WSL is provided as a network connection and not as a normal folder.

I installed the WSL extension for VSCode and this works now. Probably VSCode uses the WSL Git now and access the file system in a different way. I will give VSCode a try ;)

[dscho]

Just a hunch: do you have core.untrackedCache enabled? That might not work well across network share boundaries (the Linux file system is not a native Win32 file system).

Since you called out VS Code, it should actually work natively within your WSL2 container (only showing the GUI as Windows process, but the backend should run as Linux process). That should work better. It does on my end.