Linux: watcher stops working when workspace contains inaccessible files

[tkoop]

Issue Type: Bug

Description of the problem:
When VS Code starts up, a notification (in the bottom right corner) appears saying "File changes watcher stopped unexpectedly. A reload of the window may enable the watcher again unless the workspace cannot be watched for changes."
Reloading the window does not fix the problem.
I can confirm that the file changes watcher is not working, because when I change a file, the Source Control list of changes does not update automatically like it used to. (When I manually click the refresh button on the Source Control panel, it does refresh and correctly report the change.) So I have to conclude that the Source Control panel is working correctly; it just doesn't get notified of a change by the File Changes Watcher.
This only started happening in the latest version (1.63). Version 1.62 seems to work correctly.
I have tried increasing my inotify number, but that doesn't solve it (cat /proc/sys/fs/inotify/max_user_watches reports 524288)

Steps to Reproduce:

• Start with an existing Linux Mint operating system
• Make sure VS Code is not installed ("apt purge code")
• Just to be sure, delete the .vscode folder in your home diroectory
• Just to be sure, delete the .config/Code folder in your home directory
• Install VS Code with "apt install code"
• This will install VS Code with no extra modules and not linked to any account.
• When VS Code opens, that notification will appear and file changes will not be noticed.

Expected results:
I want the file changes watcher to not stop, and as a result of that, I want the Source Control panel to automatically report changes

VS Code version: Code 1.63.0 (7db1a2b, 2021-12-07T05:16:45.441Z)
OS version: Linux x64 5.4.0-91-generic
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz (8 x 2400)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software skia_renderer: enabled_on video_decode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	2, 3, 3
Memory (System)	15.41GB (0.32GB free)
Process Argv	--unity-launch /home/timk/Projects/crm --crash-reporter-id 3b22922c-1bb1-4a16-9314-3dce18cac82b
Screen Reader	no
VM	0%
DESKTOP_SESSION	cinnamon
XDG_CURRENT_DESKTOP	X-Cinnamon
XDG_SESSION_DESKTOP	cinnamon
XDG_SESSION_TYPE	x11

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30384385
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedt:30391933
pythonvspyt187:30373474
vsaa593cf:30376535
pythonvs932:30410667
vscop804cf:30404767
vscop341:30404997
vsrem710cf:30405999
vscexrecpromp3t2:30407763

[bpasero]

Please see if you can find any logged output that could help us find the source of the issue:

• run code --verbose from the command line and attach the output
• in Code select Help | Toggle Developer Tools and select the Console
• attach any output you see in the Console you can find

Also, does this reproduce with any folder you open?

[tkoop]

Thanks for replying, Benjamin.

That was great idea that only some folders might throw this bug. Yes, this only happens on certain folders. I spent a few minutes looking into it, and I think I've found the problem. If there is a folder in the project that is owned my someone else (like root), and that folder has permissions that I can't read (like 700), then the file changes watcher stops.

Here is a screenshot of a project that fails for me:

Also, here is output from the "code --verbose" command like you asked for.
verbose_output.txt

Also, here is the Developer Tools log that you asked for.
vscode-app-1639260290421.log

Here are a few interesting lines from the Developer Tools log:

The above is a fake project of course, but in real life my project is a web app that has a database running in a docker container. This docker container stores its database files in a folder in my project under some strange ownership. I don't want to touch the ownership of that folder, because then it might stop working. I've had problems with this before. I mention this just to say that my particular scenario might not be all that uncommon--I suspect a lot of developers store docker data in their project.

Oh, and if you're wondering if my database folder is mentioned in .gitignore, yes it is. So maybe the file watcher should check .gitignore before trying to watch files.

Thanks for looking into this, Benjamin. I'll probably use an older version of VS Code until this gets fixed.

[bpasero]

@tkoop yeah those are some good findings, as a workaround you should be able to fix this by configuring files.watcherExclude with the path to that folder. The path can be absolute or workspace relative.

Update: oh, it looks like the exclude does not help in this case.

Anyway, I thought I had fixed the issues around the watcher not stopping to work when encountering issues on the file system accessing a folder recursively from the workspace, but looks like this might be a case I have not fixed yet. I will take a look, but probably needs an upstream fix in https://github.com/parcel-bundler/watcher