Deleted root folders persist and cause global search to fail in remote workspaces

[sfsccn]

Summary

If one of the root folders in a workspace is deleted outside of VSC, it remains in the workspace explorer even after refresh. Moreover, in a remote Linux workspace this causes global search to fail with a cryptic error message so that users may have no idea what’s causing the error. This is how I came across this issue - it took a long time to determine that global searching was failing because I had renamed a root folder (or perhaps renamed the parent directory of a root folder, which has the same effect).

• VSCode Version: 1.36.1 and 1.37.0-insiders
• OS Version: Windows 10 Pro v1809

Steps to Reproduce

1. Create a workspace with folders FolderA and FolderB
2. In the OS, outside of VSC, rename FolderB to FolderC
3. Refresh the explorer

Expected: not clear, should probably at least remove the nonexistent FolderB
Actual: FolderB remains, but no files are shown

4. Select Copy Path on FolderB and view the clipboard

Expected: not clear
Actual: the clipboard contains the original path to FolderB which no longer exists

5. Perform a global search

Expected: works
Actual:

• Works as expected in a local Windows workspace
• Fails in a remote Linux workspace with a message like this one that appears directly in the search box:

spawn /home/me/.vscode-server/bin/2213894ea0415ee8c85c5eea0d0ff81ecc191529/node_modules/vscode-ripgrep/bin/rg ENOENT

Does this issue occur when all extensions are disabled?

• Local Windows workspace: yes
• Remote Linux workspace: n/a, need the extension "Remote - SSH"

[isidorn]

So this request is to watch roots, and if a root gets deleted that the code-workspace gets automatically updated. Thus forwarding to @sandy081
fyi @bpasero

[bpasero]

I am not convinced we should remove root entries from the workspace file when a root gets removed because it could easily be a remote server or attached drive that gets disconnected. So -1 for doing that automatically. However a disconnected root should not cause operations on other folders to work, e.g. like search.

[sfsccn]

Highlighting problematic root entries (fails to exist, fails to have read permission, etc), maybe using a red or grey font, would be useful (in addition to removing from search and other things that would break).

[bpasero]

@isidorn a root folder that is invalid is no longer decorated in the file explorer, can you check that? Regression?

[sfsccn]

Hi @bpasero, not sure if you were asking me, but in my explorer a deleted root folder (B renamed to C) seems to display the same as a normal one (screenshot below). This is from a Windows workspace, but the same is true in a remote Linux workspace. Maybe I'm misunderstanding what decorated means? Could it be file icon theme-dependent? I tried other themes and didn't see a difference.

[bpasero]

No, I think we used to show an exclamation mark when a root folder cannot resolve. We seem to no longer have that. (cc @sandy081)

[isidorn]

@bpasero yes, I can reproduce and acknowledge the issue. Created this one to track it #78510
I can reproduce with stable, thus we can fix in august

[sandy081]

A deleted folder should be shown with warning (!) in UI. Also features like search should ignore it. It is the same case when there is an invalid folder in the workspace configuration file.

Since @isidorn has captured explorer issue separately, assigning @roblourens for search here.

[roblourens]

Got #76654 for that