[wsl] missing file events when open on 'mnt/c`

[ghost]

Issue Type: Bug

The File Explorer in VS Code does not change after creating or deleting a file on WSL. But this doesn’t happen on Windows.

Step to reappearance:

1. Open a folder in VS Code.
2. Create a new file using the terminal instead of the File Explorer in VS Code.

Then you can see that the File Explorer in the VS Code does not display this file.

If you try to create this file again using the File Explorer in VS Code, VS Code will prompt this:

"Unable to create file 'VS Code-remote://wsl+ubuntu/{FilePath}' that already exists when overwrite flag is not set"

VS Code version: Code 1.48.2 (a0479759d6e9ea56afa657e454193f72aef85bd0, 2020-08-25T10:13:11.295Z)
OS version: Windows_NT x64 10.0.19041
Remote OS version: Linux x64 4.19.104-microsoft-standard

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz (12 x 1608)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: enabled rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.80GB (5.35GB free)
Process Argv
Screen Reader	no
VM	30%

Item	Value
Remote	WSL: Ubuntu
OS	Linux x64 4.19.104-microsoft-standard
CPUs	Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz (12 x 1608)
Memory (System)	12.33GB (9.31GB free)
VM	0%

Extensions (19)

Extension	Author (truncated)	Version
masm	blt	0.0.4
javascript-ejs-support	Dig	1.3.1
vscode-language-pack-zh-hans	MS-	1.48.3
remote-containers	ms-	0.134.1
remote-ssh	ms-	0.51.0
remote-ssh-edit	ms-	0.51.0
remote-wsl	ms-	0.44.5
vscode-remote-extensionpack	ms-	0.20.0
material-icon-theme	PKi	4.2.0
glassit	s-n	0.2.2
swig-tpl	zha	0.0.6
material-theme	zhu	3.8.7
code-runner	for	0.11.0
vscode-language-pack-zh-hans	MS-	1.48.3
python	ms-	2020.8.106424
cpptools	ms-	0.29.0
indent-rainbow	ode	7.4.0
language-stylus	sys	1.11.0
tabnine-vscode	Tab	3.0.0

(1 theme extensions excluded)

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Restore previously opened, SAVED files when open a file from Windows File Explorer (#90261)

[isidorn]

I think this is expected behavior from the explorer. Forwarding to @aeschli for wsl smarts

[aeschli]

Is the file located on /mnt/c?
Is it on WSL1 or WSL2 ?

[ghost]

The file located is on /mnt/c. It is on WSL2.

[aeschli]

There's a known WSL2 issue that 'File changes made by Windows apps on Windows filesystem don't trigger notifications for Linux apps' : microsoft/WSL#4739

When I create new files in the WSL terminal (integrated or external) I see the file appear in the explorer.

[ghost]

But when I create new files in the WSL terminal, I can't see the file appear in the explorer.

[aeschli]

Ok, can you

• run Developer: Set Log Level... and pick Trace
• open the Output view, Log (Remote Server) tab.
• create a new file

You should see an entry like that:

[ghost]

When I created the file, I didn't see the new entry.

[ghost]

I think I found the problem:

If I open an external terminal and create a new file in the working directory, do not close the terminal, and then open VSCode, the explorer will work.

But if I close this external terminal and restart VSCode, the explorer won’t work.

[aeschli]

Can you give the precise steps? Here is what I understand

• close VSCode

• open an external WSL terminal on /mnt/c/Users/me, create a file with echo foo > test1.txt

• open VSCode on /mnt/c/Users/me

• VScode explorer shows test1.txt

• close VSCode

• close terminal

• open an external WSL terminal on /mnt/c/Users/me, create a file with echo foo > test2.txt

• close external WSL terminal

• open VSCode on /mnt/c/Users/me

• VScode explorer shows test2.txt

[ghost]

OK. This is my steps:

• close VSCode
• open an external WSL terminal on /mnt/c/Users/me, create a file with echo foo > test1.txt
• open VSCode on /mnt/c/Users/me
• create a file with echo foo > test2.txt
• VSCode explorer shows test1.txt and test2.txt
• close VSCode
• close terminal
• open VSCode on /mnt/c/Users/me
• open an external WSL terminal on /mnt/c/Users/me, create a file with echo foo > test3.txt
• VSCode explorer doesn't show test3.txt

[aeschli]

I can reproduce: when opening on /mnt/c/Users/me, no file events. Opening on /mnt/c/Users/me/folder, there are events

Interesting message: Error: Circular symlink detected:

[2020-11-05 17:32:01.801] [remoteagent] [trace] [File Watcher (chokidar)] Start watching with chockidar: /mnt/c/Users/martinae, excludes: **/.git/objects/**,**/.git/subtree-cache/**,**/.hg/store/**,**/node_modules/*/**,/home/aeschli/.vscode-server-insiders/extensions/**,**/*.asar, usePolling: false
[2020-11-05 17:32:03.078] [remoteagent] [warning] [File Watcher (chokidar)] Error: Circular symlink detected: "/mnt/c/Users/martinae/AppData/Local/Application Data" points to "/mnt/c/Users/martinae/AppData/Local"

[Diego1149]

What is the status of this?

[aeschli]

We now use polling when watching the Windows file system mounts.
You can test that in the latest (1.54) insiders builds (Remote - WSL extension >= 0.54.0, requires 1.54)

[ggirard07]

According to note in iteration plan for February 2021, this has been addressed for Remote WSL.
But does it solves the same issue occurring when using Remote Container extension with Docker Desktop configured with WSL2 engine?

[PavelSosin-320]

@aeschli In addition. WSL Kernel 5.4.9 lacs of significant security feature related to this issue:
auditctl -s
Error - audit support not in kernel
Cannot open netlink audit socket
This is crucial for any OCI runtime running in WSL requiring Syscall filtering or auditing. I hope that MS will correct this issue ASAP.

[aeschli]

@ggirard07 No, this doesn't address any remote container issues. Is there an issue against remote containers for this? if not, can you file an issue with steps to reproduce? FYI @chrmarti

@PavelSosin-320 Sorry, not sure how your comment is related to this issue. Should this be filed against wsl?

[PavelSosin-320]

@aeschli Yes, I already sent feedback on this issue. When I look at the WSL boot log I see
Mar 03 11:03:09 MSI-wsl auditd[29]: Error - audit support not in kernel
Mar 03 11:03:09 MSI-wsl auditd[29]: Error - audit support not in kernel
although I explicitly added audit=1 to the Kernel parameters in .wslconfig. It means that Microsoft's WSL Kernel is built without Kernel Syscalls auditing. It includes file and read-write operations. It harms many things: no file events, no syscall filtering required by seccomp builtin into Recent Docker and Podman as a security feature. When I look into /var/log/audit/audit.log
The meaning is that Containers and other programs interested in new file creation and deletion. get no notifications, i.e. - missing file events.

[ggirard07]

@aeschli I thought https://github.com/microsoft/vscode-dev-containers repo was only for prebuilt container images available from the container extension, not issues with the extension itself.
https://github.com/microsoft/vscode-remote-release was for issues for any flavor of remote development in VS Code, either be WSL or containers.
Am I wrong?

[PavelSosin-320]

If Linux Kernel doesn't emit FS events or filter Syscalls incorrectly it impossible to predict what comes to the NodeJS as the filesystem events. Docker's RunC and Podman's CRun get FS notifications from the Kernel in the same way.
I suppose it will affect Docker and Podman diff and sure the Docker 20.10 /Podman 3.0 security feature that allows running rootless containers with controlled access to the kernel because I came here from The Podman 3.0 on WSL testing. Podman expects to receive events from The Kernel via audit. If It can't register itself as a listener it fails. It happens in my tests. If the audit daemon fails and auditctl says that something missed in the Kernel and it's impossible to attach an event listener such a problem may affect Nodejs or any other program. It is not a configuration - I start WSL kernel with audit=1 option and no filters. It didn't help.

[aeschli]

@ggirard07 You are correct, https://github.com/microsoft/vscode-remote-release is the issue tracker for all the remote extensions (wsl, containers and ssh). It's just that each extension has a different code base, and different owners. So this bug is against the remote-wsl extension and the fix I made is just for remote-wsl.

[Diego1149]

My bug got closed as a dup of this, but this is fixed and the bug I created is still reproing in 1.54 with WSL extension 0.54.0

[aeschli]

For 1.56 we no longer do polling on /mnt/ with WSL2. We got too many issues raised regarding the bad performance of the polling.

The polling setting remote.WSL.fileWatcher.polling still exists, but only applies to WSL1, as before.

We currently have no workaround for this but are waiting for WSL to come up with a solution

I created #5000 as fresh issue to track the progress on this.