code-server icon indicating copy to clipboard operation
code-server copied to clipboard

settings files.watcherExclude not working?

Open theflyingape opened this issue 3 months ago • 4 comments

Is there an existing issue for this?

  • [x] I have searched the existing issues

OS/Web Information

  • Web Browser: latest Chrome
  • Local OS: Windows
  • Remote OS: RHEL 9
  • Remote Architecture: x86_64
  • code-server --version: 4.104.2 b0992ddb3e3b398371da6bcfbe21a70b4d66eb8d with Code 1.104.2

Steps to Reproduce

Our main project folder contains subfolders that make use of autofs + rclone. We do not want code-server attempting to traverse the MANY remote endpoints configured. The solution should be to use VS Code settings files.watcherExclude as implemented from https://github.com/microsoft/vscode/issues/150174

I have this setting in both the FOLDER (/files) and Workspace settings, but it appears to be ignored. Or is there another place to best handle this override?

{
    "files.watcherExclude": {
        "**/**": true,
        "**": true,
        "*": true
    }
}

That should effectively disable files watching completely. Optimally, I would like to use targeted filtering instead (which also does not have any effect) of globally excluding:

{
    "files.watcherExclude": {
        "/*files/cifs/**": true,
        "/*files/nfs/**": true,
        "/*files/s3/**": true,
        "/*files/sftp/**": true
    }
}

Expected

When I do df, I should not see any remote filesystems mounted.

Actual

As soon as I open the project workspace, it begins to crawl through all of the folders, which in turn, begins to mount every endpoint to do more crawling -- ugh!!

Logs


Screenshot/Video

No response

Does this bug reproduce in native VS Code?

Yes, this is also broken in native VS Code

Does this bug reproduce in GitHub Codespaces?

Yes, this is also broken in GitHub Codespaces

Are you accessing code-server over a secure context?

  • [ ] I am using a secure context.

Notes

No response

theflyingape avatar Sep 30 '25 16:09 theflyingape

Yes, this is also broken in GitHub Codespaces

To confirm, you reproduced this issue in Codespaces? I assume maybe not since this involves remote mounts?

I am not exactly sure what VS Code does with these entries or how it works so it might make sense to ask upstream (they may want you to reproduce with code serve-web instead of code-server), but I wonder if the /*files is not right? When I did /*home/path/** it did not work but /home/path/** did work.

The setting text says any glob patterns are matched relative from the watched folder. Do you have / open in code-server or some sub-path?

code-asher avatar Sep 30 '25 20:09 code-asher

Apologies on those 'Yes' reproducible responses in the ticket. Yes, my Workspace opens /files (a link to /hcdev-files) running on dev or /files (a link to /hctest-files) running on test, etc.

I tried a lot of exclusion patterns, such as **/cifs/** **/sftp/** etc. to no improvement.

My sad workaround is to disable browse = no in autofs so the remote mount points are not visible (when not mounted) and therefore code server cannot traverse them.

theflyingape avatar Oct 02 '25 10:10 theflyingape

Interesting, you may want to see if you can reproduce with native VS Code (code serve-web), if it reproduces with that we can report it upstream in the VS Code repo and they will probably have a better idea of the issue. If it does not reproduce then it means we broke it here in code-server although I am not sure what we could have changed to cause that. 🤔

I wonder if the link confuses it?

code-asher avatar Oct 02 '25 19:10 code-asher

Yeah, it looks like any links under a workspace folder in general are ignored by watcher, because when I do lsof for processes that have those paths pointed to by a link opened, none of my code-server threads show up.

So I replaced my workspace folders path = "/files" with the real filesystem mount path = "/hcdev-files", and I also added to .vscode/settings.json those relative exclusion patterns cifs/**, nfs/**, s3/**, and sftp/** alongside any **/cifs/**, etc.

Sadly, none of that had the desired effect.

theflyingape avatar Oct 02 '25 20:10 theflyingape