VSC unable to watch for file changes in this large workspace weird

Visual Studio-Code

Visual Studio-Code Problem Overview


I just started using VSCode version 1.24.1.

After loading a folder, it shows warning

> Visual Studio Code is unable to watch for file changes in this large workspace

After i check the limit as suggested on their guide, using

cat /proc/sys/fs/inotify/max_user_watches

I get 8192, while my project has only 650 files (of which 400 are inside .git)

Why does this happen? Is this a bug or am I missing something?

(Increasing the limit is clearly not the right solution.)

Visual Studio-Code Solutions


Solution 1 - Visual Studio-Code

what linux ppl dont know, there are ppl new to linux like me. So if you're a noob, this is for you.

  1. Open a new terminal.
  2. cat /proc/sys/fs/inotify/max_user_watches (might be a number 8k+)

now (a) for vim-Editor

  1. (a) sudo vim /etc/sysctl.conf
  2. (a) go all the way down and add a new line with: fs.inotify.max_user_watches=524288 (make sure you DONT have a # in front of the command)
  3. (a) type :wq! and press enter

or (b) for nano-Editor (thanks to @bradrar)

  1. (b) sudo nano /etc/sysctl.conf

  2. (b) go all the way down and add a new line with: fs.inotify.max_user_watches=524288 (make sure you DONT have a # in front of the command)

  3. (b) type ctrl + x, type y and press enter


  1. type sudo sysctl -p
  2. type again: cat /proc/sys/fs/inotify/max_user_watches (should be 500k+ now)
  3. (thank me later.)

Solution 2 - Visual Studio-Code

The solution I found and it's work for me is

add this line fs.inotify.max_user_watches=524288 in to /etc/sysctl.conf

and then run the command sudo sysctl -p

and then go to your vscode settings find a file called settings.json

and this line to it

"files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/node_modules/*/**": true
  }

you can also refer this link https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc

Solution 3 - Visual Studio-Code

The fact that you are out of watches does not mean that its VSCode's fault.

VSCode has for sure issues with excluding directories from watch (on linux) (update: most are recently resolved here, and here)

But since you have counted the files yourself, the error message in this case is probably misleading and some other application has already exhausted watches.

To trace the guilty app you can use this nice script

Solution 4 - Visual Studio-Code

In my case I do not have enough privileges to change the sysctl.conf, so my solution for Ubuntu 18.04 LTS was:

sudo /bin/su -c "echo 'fs.inotify.max_user_watches=524288' >> /etc/sysctl.conf"
sudo sysctl -p

Solution 5 - Visual Studio-Code

In my case (PHP using Composer), I had to exclude vendor path from watching

enter image description here

Depending on your case, you should exclude your dependencies folder.

Solution 6 - Visual Studio-Code

Here is the solution : https://code.visualstudio.com/docs/setup/linux

The limit can be increased to its maximum by editing /etc/sysctl.conf and adding this line to the end of the file: fs.inotify.max_user_watches=524288

The new value can then be loaded in by running sudo sysctl -p

Solution 7 - Visual Studio-Code

Following settings worked for me (inside .vscode/settings.json, you can also put them at user level / system level settings in vscode instead of workspace level settings)

"files.watcherExclude": {
        "**/.git": true,
        "**/.DS_Store": true,
        "**/node_modules": true,
        "**/some-soft-link-to-higher-level-directory-in-my-file-system" : true,
        "**/.cache-loader" : true
}

.git, node_modules are perhaps excluded by default, but depending on your workspace, you may need to add others. As an example, I had a soft link to a higher level directory in my file-system (which recursively had 100s of thousands of files). Similarly, .cache-loader often has thousands of files.

Possibly useful note: it took me some time to realize that files.exclude and files.watcherExclude are two different settings.

Some theoretical opinion: Most answers here (and even in the official vscode documentation) suggest increasing the system watcher limits to a very large number. This works okay in most cases, however, it is like using a hammer in place of a screwdriver (is brute force, may not always work, and is not efficient). While the absolute system limit can (and perhaps should be) raised from the default limit, it is beneficial to optimize your workspace and avoid using unnecessary system resources.

Solution 8 - Visual Studio-Code

Oct. 2021: this is improved from VSCode 1.61 (Sept. 2021, see below)

VSCode 1.62 includes:

> ## File watching changes

> File watching in VS Code changes to a new library, thanks to the work of the Parcel team with their @parcel/watcher.
We will gradually roll out this change to all users in the upcoming weeks.
Linux users will be happy to learn that the files.watcherExclude now applies natively so that the number of file handles VS Code needs to open for file watching can be greatly reduced. > > The existing files.legacyWatcher setting was changed to an enumeration with these values: > > - on - The new file watcher will never be used. > - off - The new file watcher will always be used. > - default - The new file watcher will only be used when you open multi-root workspaces (via .code-workspace file).


Feb. 2021: As noted in issue 40898, the issue persists for multi-root workspace (see the last part, for VSCode 1.61 improvements)

> Initial problem is that npm install takes twice as long to install dependencies when VSCode is running. > > I've figured out that this is because of file watching for node_modules folder so I added it to files.watcherExclude.
> > I uses following combinations (but non of them seems to be working): > >yaml >"files.watcherExclude": { > "**/node_modules": true, > "**/node_modules/**": true, > "**/node_modules/*/**": true > } >

This comment points out a script from Dirk Feytons to see which inotify watches are actually being created to confirm whether my watcher excludes were being used or not.

/*
 * If you want to see which inotify watches are being created by an application then you can
 * use this simple piece of code, compile it to a shared library and LD_PRELOAD it when starting
 * the application. Keep an eye on syslog to see the list of watches.
 * **NOTE**: this only logs the watches, it won't actually create the watch and thus watching
 * for changes WON'T actually WORK!
 *
 * More details (adjust as needed for your environment/distribution):
 * - Save this file in e.g. $HOME/inotify.c
 * - Compile: gcc -shared -o inotify.so inotify.c
 * - Start monitoring syslog: tail -f -n 0 /var/log/syslog | tee $HOME/watches.log
 * - Run your application with: LD_PRELOAD=$HOME/inotify.so <application>
 */

#include <sys/inotify.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <syslog.h>

int inotify_add_watch(int fd, const char *pathname, uint32_t mask)
{
    syslog(LOG_USER | LOG_ERR, "********** [%u] inotify_add_watch for %s", getpid(), pathname);
    return 100000;
}

Update Sept. 2021, from Lionel Gatibelza:

> I was able to fix the problem, I don't know the real cause and why Vscode perform this check for the error, but I did the known fix on the remote server and on my local machine: > > - Add this fs.inotify.max_user_watches=524288 to /etc/sysctl.conf > - Reload the configuration: sudo syctl -p > - Close and reopen Vscode > After that i didn't have the error again!

And from issue 132483 from Benjamin Pasero (software engineer at Microsoft in Zurich):

> Just to clarify, nsfw is used on Windows as well in multi-root workspaces.
It was our original intent 5y ago to replace all other watching solutions with nsfw so we enabled it only for multi-root scenarios, which targets a lower user base (maybe 200.000 users) to get some testing and feedback.
The next step in this journey is to enable it for all users and remove the others. > > PS: the only platform where nsfw is currently not enabled by default (unless you are in multi-root workspace) is Linux because unfortunately nsfw does not support ignore patterns (our files.watcherExclude setting) and each folder in a hierarchy is counted as a opened file handle against the limited set of file handles in the OS, forcing users to increase that limit.
Plan is to implement that support in October and then also get Linux on board.


Sept. 2021, VSCode 1.61:

> ## File watching changes > > The file watcher used to detect changes to files and folders on disk changed to a library that can handle all of our supported platforms (Windows, Linux, macOS) and reduces the overhead of maintaining different watchers for different platforms. > > We plan to enable this library by default on all platforms. This iteration we enabled it on Windows and macOS, while Linux is planned shortly after. > > The new watcher should be faster on startup and result in fewer CPU cycles spend on large folders. > > One downside of using the library is that the file watcher no longer automatically detects folders in a workspace that are symbolic links on macOS.
If you have such a setup, you can use the new files.watcherInclude setting to explicitly add symbolic link paths to include for file watching. > > On the upside, you can use this new setting on Windows to explicitly include symbolic link folders inside the workspace - something that was not possible before on Windows. > > You should not notice any difference in your day to day work, but if file watching is broken for you, please report an issue.
There is a setting files.legacyWatcher to enable the old watcher in case of problems.

Solution 9 - Visual Studio-Code

TL; DR;

Seems like a bug.

-----

It seems the warning is gone now.

Unfortunately I cannot reproduce the bug right now, but here are some steps.

  • Installed Php Intellisense extension
  • From linux terminal did git init
  • Added folder into workspace
  • Did some work, added, saved, commit and push from command palette
  • closed VSC
  • Opened VSC -> warning was shown.

At this moment i saw in htop that there was a process /usr/share/code with long arguments which included something with TypeScript that was using 100% of 1 CPU and around 1G RAM. Then

  • closes VSC
  • killed process
  • opened VSC

Now the warning is not showing anymore, also CPU is being used normally.

Solution 10 - Visual Studio-Code

What helped me was creating a separate workspace for the project i was working on. So if i'm working on something in /htdocs/project/ then instead of just opening that folder i create it as a workspace.

Solution 11 - Visual Studio-Code

If you are using for JavaScript development, there is a workaround:

Just disable this built-in extension: TypeScript and JavaScript Language Features

TypeScript and JavaScript Language Features

Solution 12 - Visual Studio-Code

If you are writing Javascript, then this is probably gonna work for this issue:

You have to access the side-bar extensions menu: Ctrl + Shift + X.
Then type: @builtin types and disable the extension: TypeScript and JavaScript language features.

Solution 13 - Visual Studio-Code

I followed the recommendations from https://stackoverflow.com/users/4270633/harsh-shah[harsh-shah][1]

Almost worked for me. I discovered I had resources in my project that were also being watched unnecessary.

VScode behavior seems to be watch everything, unless excluded.

If you find you have a couple hundred files in your project but have 32000 watchers - you may want to inventory what is in your project directory and exclude unnecessary directories.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionDonJoeView Question on Stackoverflow
Solution 1 - Visual Studio-CodeAndre ElricoView Answer on Stackoverflow
Solution 2 - Visual Studio-CodeHarsh ShahView Answer on Stackoverflow
Solution 3 - Visual Studio-CodeMarinos AnView Answer on Stackoverflow
Solution 4 - Visual Studio-CodeSandroMarquesView Answer on Stackoverflow
Solution 5 - Visual Studio-CodeAhmed IsmailView Answer on Stackoverflow
Solution 6 - Visual Studio-CodeHareeshView Answer on Stackoverflow
Solution 7 - Visual Studio-CodeworkwiseView Answer on Stackoverflow
Solution 8 - Visual Studio-CodeVonCView Answer on Stackoverflow
Solution 9 - Visual Studio-CodeDonJoeView Answer on Stackoverflow
Solution 10 - Visual Studio-CodeRogerKView Answer on Stackoverflow
Solution 11 - Visual Studio-CodemdmundoView Answer on Stackoverflow
Solution 12 - Visual Studio-Codeuser14183068View Answer on Stackoverflow
Solution 13 - Visual Studio-CodeteraryView Answer on Stackoverflow