vscode editor does not update contents on NFS share

[virtuald]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.100.2
• OS Version: Ubuntu 22.04 (5.15.0-139-fips)

Steps to Reproduce:

1. Open vscode
2. Open a file in the editor
3. Change that file from outside the editor
4. Editor contents should change
   a. On NFS share it fails with EUNKNOWN error
   b. Works fine opening directory on local disk

This was previously reported in #204466 but that reporter was not able to assist with debugging -- I'm not a javascript developer, but I should be able to run things locally.

I feel like this issue started after we switched to a FIPS-enabled kernel so it's likely that some weird security setting is getting in the way. The other reporter was on RHEL8 so they might also be on some strict corporate network.

I notice that the other reporter's error messages have File Watcher (parcel) but mine only say File Watcher] Unexpected error: Invalid argument (EUNKNOWN) (path: /path/to/workspace).

I have ran the following code with the @parcel/watcher package courtesy of ChatGPT:

const watcher = require('@parcel/watcher');
const path = require('path');

// Directory to watch
const directoryToWatch = '/disk2/dustin/watcher';

// Function to handle file changes
const handleFileChange = (err, events) => {
  if (err) {
    console.error('Error:', err);
    return;
  }

  // Print out changes
  events.forEach(event => {
    console.log(`${event.type}: ${event.path}`);
  });
};

// Watch the directory
watcher.subscribe(directoryToWatch, handleFileChange).then(subscription => {
  console.log(`Watching for changes in ${directoryToWatch}...`);
}).catch(error => {
  console.error('Failed to watch directory:', error);
});

It works fine and outputs file modification events whereas the vscode watcher does not. I tried to duplicate the vscode watcher... but I'm not a javascript developer.

If you have things I can try to flush out this issue, I can probably run them -- but I don't have administrative rights or the ability to bring brand new software in without a lengthy process, and it's on a disconnected network that I can only bring data out via typing it.

Note: I'm actually running 1.100.1 but I changed the .2 to make the bot happy. Given this issue has been around for awhile and it's likely related to a local configuration issue, I can't imagine .2 fixed it.

[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
• reproduce the issue
• attach the log files you find from running the command "Open Logs Folder"

Thanks!

[virtuald]

Does code --verbose produce output different than enabling tracing as mentioned in https://github.com/microsoft/vscode/wiki/File-Watcher-Issues?

[bpasero]

@virtuald it ensures that the logs are in tracing mode right on startup, so you will find a "File Watcher" output channel with all the info for me to look at.

[virtuald]

logs.zip
This isn't all of the logs, but snippets of ones that seem relevant (I inserted a -snip- where I removed content)

[bpasero]

Thanks, I see no other error than the reported one, it looks like file watching simply does not work for that NFS share /home/virtuald/watcher. I do not think there is something we can do about it, we just hand off the path to parcel watcher here:

vscode/src/vs/platform/files/node/watcher/parcel/parcelWatcher.ts

Line 363 in 0bdb1d7

const parcelWatcherInstance = await parcelWatcherLib.subscribe(realPath, (error, parcelEvents) => {

[virtuald]

it looks like file watching simply does not work for that NFS share /home/virtuald/watcher

Not true. The example code above does work on that exact same path, so watching files on that NFS can work. It must be something in how vscode is using parcel, or some other environmental thing (for example, I'm using node 12 to run it because that's what comes with ubuntu).

Is there an easy way where I could run javascript code in the context of a built vscode and run file watcher code so that I could try to debug this? There's no way I could get approval to bring in all the development tooling for a custom build of vscode, but maybe running in vscode context would be enough.

[bpasero]

@virtuald is there any way I could create such a NFS myself or get access to a test environment of yours, then I could try to reproduce from my end.

Otherwise, its relatively easy to get to a state to run VS Code from its sources so that we can add some more debugging: https://github.com/microsoft/vscode/wiki/How-to-Contribute

Btw to match the same node version VS Code is using, you would have to use node.js 22.

[virtuald]

I have a question out to IT to see if there's a good way to reproduce this on a different network.

As an interesting data point, on a different (but similar) network we have Ubuntu 22 with VSCode 1.95 and RHEL8 with VSCode 1.100.1 -- the Ubuntu 22 machine has the same problem I reported for a directory on our NFS share, but the RHEL8 machine's inotify watcher in VSCode works perfectly fine on the exact same directory.

Certainly seems like a configuration issue, but maybe there's something we can do to detect it so that vscode can warn users about it.

[virtuald]

We are still working on reproducing this in a different environment, thanks for your patience.

[virtuald]

Still no reproducer, but on a whim I ran strace -f -o vscode.txt -- code --verbose folder. Interestingly, there are no inotify calls failing anywhere in the trace -- and it never tries to do inotify_add_watch for the workspace directory. I verified on the working system that you see an inotify_add_watch succeed for the workspace directory.

Looking at parcelWatcher.ts it's clear now that the error logger doesn't really tell us what's failing, and there's quite a few different places where it can be called from.

In the strace there are lots of system calls failing with Invalid argument, but almost all of them are various calls to prctl. The one exception is a call to madvise, but that doesn't seem related?

I think the next course of action is for me to set up a development environment on that network so I can see the error occur with better logging.