1.37 Explorer not showing any files or folders

[huili80]

• VSCode Version:
• OS Version:

Steps to Reproduce:

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

[jrieken]

/needsMoreInfo

Please update this issue after reading https://github.com/Microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions#writing-good-bug-reports-and-feature-requests. Thanks.

[vscodebot]

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.

Happy Coding!

[zeil]

I have the same issue when using sshfs. But not for all mounted directories.

[bpasero]

Need exact steps how to reproduce.

[huili80]

I do not know how to reproduce, it appears to only happen in one of my dev env at work (it runs on suse enterprise sever 12 linux os), in all workspaces and folders i tried to open there. On a different work computer (also suse enterprise sever 12) i don't have this problem at all.

The symptom is that when i open any workspace or folder in vscode, the explorer tree only shows a list the folders themselves, nothing in the folders shows (files or sub-dirs).

when i revert back to 1.36 then it's all good. so i guess i can stay on 1.36 until 1.38 comes out. hopefully if other people experience the same problem maybe they could provide more info.

[bpasero]

@huili80

The symptom is that when i open any workspace or folder in vscode, the explorer tree only shows a list the folders themselves, nothing in the folders shows (files or sub-dirs).

Is there anything printed to the log? Can you try to open the developer tools (from Help menu) and then click on Console?

[bpasero]

@huili80 @zeil since I have a theory what this could be, can you test again with one of these builds where I reverted one change I did last month:

• Windows download
• macOS download
• Linux download

[huili80]

The insider version (linux) is good.

[bpasero]

@huili80 can you still get me from the stable version any output you see?

I suspect a regression from da5fb7d where I switched to some new API from node.js (fs.readdir(path, { withFileTypes: true }))

[huili80]

i toggled on the developer tools but i don't see anything suspicious.

here is what i see:
abstractExtensionService.ts:395 [naereen.makefiles-support-for-vscode]: Unknown language in contributes.grammars.language. Provided value: Makefile
_logMessageInConsole @ abstractExtensionService.ts:395
_handleExtensionPointMessage @ abstractExtensionService.ts:346
n @ abstractExtensionService.ts:322
_msg @ extensionsRegistry.ts:37
error @ extensionsRegistry.ts:46
_validateGrammarExtensionPoint @ abstractTextMateService.ts:287
C.grammarsExtPoint.setHandler.e @ abstractTextMateService.ts:82
_handle @ extensionsRegistry.ts:144
acceptUsers @ extensionsRegistry.ts:135
_handleExtensionPoint @ abstractExtensionService.ts:381
_doHandleExtensionPoints @ abstractExtensionService.ts:327
_handleExtensionPoints @ extensionService.ts:524
(anonymous) @ extensionService.ts:514
(anonymous) @ errors.ts:184
n @ errors.ts:184
_startLocalExtensionHost @ extensionService.ts:513
(anonymous) @ extensionService.ts:509
r @ errors.ts:184
Promise.then (async)
l @ errors.ts:184
(anonymous) @ errors.ts:184
n @ errors.ts:184
_scanAndHandleExtensions @ extensionService.ts:428
(anonymous) @ abstractExtensionService.ts:101
(anonymous) @ errors.ts:184
n @ errors.ts:184
_initialize @ abstractExtensionService.ts:97
u.runWhenIdle @ extensionService.ts:133
requestIdleCallback (async)
t.runWhenIdle @ async.ts:695
P._lifecycleService.when.then @ extensionService.ts:132
Promise.then (async)
P @ extensionService.ts:130
_createInstance @ instantiationService.ts:117
_createServiceInstance @ instantiationService.ts:216
_createServiceInstanceWithOwner @ instantiationService.ts:205
_createAndCacheServiceInstance @ instantiationService.ts:194
_getOrCreateServiceInstance @ instantiationService.ts:142
get @ instantiationService.ts:60
initLayout @ layout.ts:184
(anonymous) @ workbench.ts:142
(anonymous) @ errors.ts:184
n @ errors.ts:184
e.invokeFunction.t @ workbench.ts:136
invokeFunction @ instantiationService.ts:67
startup @ workbench.ts:136
(anonymous) @ main.ts:129
r @ errors.ts:184
Promise.then (async)
l @ errors.ts:184
r @ errors.ts:184
Promise.then (async)
l @ errors.ts:184
(anonymous) @ errors.ts:184
n @ errors.ts:184
open @ main.ts:113
t.main @ main.ts:356
(anonymous) @ workbench.js:30
Promise.then (async)
bootstrapWindow.load.removeDeveloperKeybindingsAfterLoad @ workbench.js:26
e @ bootstrap-window.js:132
t._invokeFactory @ loader.js:996
t.complete @ loader.js:1006
s._onModuleComplete @ loader.js:1623
s._onModuleComplete @ loader.js:1635
s._resolve @ loader.js:1583
s.defineModule @ loader.js:1234
o @ loader.js:1673
c @ loader.js:786
(anonymous) @ extensionManagementService.ts:13
(anonymous) @ fake:1
t._createAndEvalScript @ loader.js:789
(anonymous) @ loader.js:772
a @ loader.js:876
(anonymous) @ loader.js:885
readFileAfterClose @ internal/fs/read_file_context.js:53
console.ts:137 [Extension Host] activating extension
console.ts:137 [Extension Host] starting language server
console.ts:137 [Extension Host] ApplicationInsights:Sender ["Not saving data due to max size limit being met. Directory size in bytes is: 63030733"]

[bpasero]

@huili80 can we conduct a little experiment? It is important to run it on the machine where you see the issue:

• download node 10.11.0 from https://nodejs.org/dist/v10.11.0/
• make sure node can be run from the command line
• cd into the folder that shows up with empty children in VSCode
• run node index.js on the script below from the command line
• attach the output here

index.js

const fs = require("fs");

fs.readdir(process.cwd(), { withFileTypes: true }, (error, dirs) => {
    console.log(dirs);
});

[huili80]

ah... i'm not allowed to install node.js on my work computer, sorry.

[bpasero]

@huili80 easy, no problem. We can do this much easier:

• start VSCode
• Help > Toggle Developer Tools
• click Console
• type the contents of the file I pasted above
• replace process.cwd() with the folder that causes this trouble (surrounded by quotes)
• check the output (expand Dirent if any)

I just did that and it shows:

[huili80]

const fs = require("fs");

fs.readdir(process.cwd(), { withFileTypes: true }, (error, dirs) => {
console.log(dirs);
});
undefined
VM189:4
(142) [Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, DirentFromStats, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, Dirent, �]
[0 � 99]
[100 � 141]
length: 142
proto: Array(0)

[vfdev-5]

@bpasero I have a similar issue. I did the same stuff you asked @huili80 and here what I have.
Let say I have two folders in the workspace (all folders are mounted via sshfs):

FolderA
- file1
- file2
FolderB
<empty but should have files and some symbolic links (I suppose they are responsible for the error)>

I run

const fs = require("fs");

fs.readdir("/path/to/FolderA", { withFileTypes: true }, (error, dirs) => {
    console.log(dirs);
});

and the output is correct

(N) [DirentFromStats, DirentFromStats, DirentFromStats, DirentFromStats, DirentFromStats, DirentFromStats, DirentFromStats, ...]

However when I run the same of FolderB

const fs = require("fs");

fs.readdir("/path/to/FolderB", { withFileTypes: true }, (error, dirs) => {
    console.log(dirs);
});

Nothing is shown.

In addition if I run the same on a subfolder of the FolderB (i.e. "/path/to/FolderB/subfolder"), the results is correct.

EDIT:
And finally, when I set withFileTypes: false

fs.readdir("/path/to/FolderB", { withFileTypes: false }, (error, dirs) => {
    console.log(dirs);
});

the result is correct and displays the correct folders and files of FolderB.

HTH

[chaoticgoo]

Hi all I have added comments and screenshots with my similar experience on issue #78786 at #78786 and a few tests I ran.

In short I think it's the symlinks on the remote end that can't be followed by my local VS Code.

I'll try the commands @bpasero requested above and report back.

[chaoticgoo]

On the VM (the "remote" machine I mount with sshfs) the output is

[ Dirent { name: '__pycache__', [Symbol(type)]: 2 },
  Dirent { name: 'config.json', [Symbol(type)]: 3 },
  Dirent { name: 'controller.py', [Symbol(type)]: 1 },
  Dirent { name: 'export.py', [Symbol(type)]: 1 },
  Dirent { name: 'index.js', [Symbol(type)]: 1 },
  Dirent { name: 'main.py', [Symbol(type)]: 1 },
  Dirent { name: 'middleware', [Symbol(type)]: 2 },
  Dirent { name: 'model.py', [Symbol(type)]: 1 },
  Dirent { name: 'plugins', [Symbol(type)]: 2 },
  Dirent { name: 'public', [Symbol(type)]: 2 },
  Dirent { name: 'rules.py', [Symbol(type)]: 1 },
  Dirent { name: 'safeuwsgidecorators.py', [Symbol(type)]: 1 },
  Dirent { name: 'tables.py', [Symbol(type)]: 1 },
  Dirent { name: 'views', [Symbol(type)]: 2 } ]

On the host (my local machine), I cd to same place via the mounted folder and run the command, I get a much more verbose output so I'll just paste the portion for the one symlink file here:

 DirentFromStats {
    name: 'config.json',
    [Symbol(type)]: null,
    [Symbol(stats)]:
     Stats {
       dev: 56,
       mode: 41471,
       nlink: 1,
       uid: 1000,
       gid: 1000,
       rdev: 0,
       blksize: 4096,
       ino: 4723,
       size: 36,
       blocks: 8,
       atimeMs: 1565404329000,
       mtimeMs: 1459808602000,
       ctimeMs: 1459808602000,
       birthtimeMs: 1459808602000,
       atime: 2019-08-10T02:32:09.000Z,
       mtime: 2016-04-04T22:23:22.000Z,
       ctime: 2016-04-04T22:23:22.000Z,
       birthtime: 2016-04-04T22:23:22.000Z } },

[chaoticgoo]

For anyone looking for a workaround while hoping this can be fixed swiftly here are two that have worked for me:

1. Move any symlinked files or folders out of your project. I know, not really a solution for most, but in a pinch might help someone.
2. Create local folders that match the symlinked remote files. They can be empty files. This also isn't really a solution for most but gets the parent folders to render again in VS Code.

In my case, I only had one symlink, a config.json to /usr/local/etc/test.json on the remote machine, so I just created that file on my local laptop with {} in it and VS Code could once again let me open the folder and work with the other files in it.

[bpasero]

@vfdev-5 @chaoticgoo thanks for the testing. So I would think that we just found a bug in fs.readdir when configured with { withFileTypes: true } for when you are connected to a network drive that is using symbolic links.

The next step would be to:

• try to reproduce this with later versions of node.js, I would try with the latest https://nodejs.org/en/download/
• report this as a bug to node's issue tracker

Can anyone of you do that?

As for VSCode: I can only think of reverting that change I did to use this new API back to how it was before. We will consider this change for our recovery release.

[huili80]

Turns out i had dangling symlinks in my workspace, after i cleaned them up, it's all good now.

[bpasero]

Turns out i had dangling symlinks in my workspace

@huili80 is that a symbolic link that was pointing to a non existing target or what specifically?

[huili80]

Turns out i had dangling symlinks in my workspace

@huili80 is that a symbolic link that was pointing to a non existing target or what specifically?

@bpasero yes it was pointing to a non-existing target.

[chaoticgoo]

try to reproduce this with later versions of node.js,

Outside of VS Code, my node -v is v10.16.2, the latest 10.x version, that's as far up as I can go here.

My VS Code info is:

Version: 1.37.0
Commit: 036a6b1d3ac84e5ca96a17a44e63a87971f8fcc8
Date: 2019-08-08T01:24:14.598Z
Electron: 4.2.7
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Linux x64 4.4.0-148-generic

Output from your script from a non-VS Code terminal with node index.js for my one symlink is:

 DirentFromStats {
    name: 'config.json',
    [Symbol(type)]: null,
    [Symbol(stats)]:
     Stats {
       dev: 56,
       mode: 41471,
       nlink: 1,
       uid: 1000,
       gid: 1000,
       rdev: 0,
       blksize: 4096,
       ino: 4723,
       size: 36,
       blocks: 8,
       atimeMs: 1565404329000,
       mtimeMs: 1459808602000,
       ctimeMs: 1459808602000,
       birthtimeMs: 1459808602000,
       atime: 2019-08-10T02:32:09.000Z,
       mtime: 2016-04-04T22:23:22.000Z,
       ctime: 2016-04-04T22:23:22.000Z,
       birthtime: 2016-04-04T22:23:22.000Z } },

To be clear to anyone just stumbling across this who hasn't read all the related issue threads, this symlink is not actually dangling on the remote Linux system where these files really live. It only appears to be dangling when viewed from my local Linux machine. I have mounted the remote parent folder over sshfs and the latest VS Code no longer copes with these remote symlinks.

Thanks for your help @bpasero !

[bpasero]

@chaoticgoo to clarify:

Output from your script from a non-VS Code terminal with node index.js for my one symlink is:

Is that different from what you see inside VSCode or the same? I am wondering if your node version already contains a fix.

[bpasero]

Hm, I do wonder if nodejs/node#22808 (which came exactly right after our node.js version) is the fix for this.

To try it out, can anyone try the scenario from our exploration builds? They ship with a much newer node.js version:

• macOS: Download
• Linux (DEB): Download
• Linux (RPM): Download
• Windows: Download

[chaoticgoo]

Is that different from what you see inside VSCode or the same? I am wondering if your node version already contains a fix.

Both the VS Code terminal and a normal Linux terminal (both on the local machine) give the output I pasted but I reread your instructions and ran the commands in Dev Tools inside VS Code and it fails on a folder with these remote symlinks (returns Undefined). It returns a list of files and properties as above on folders that don't have remote symlinks.

See below:

I'll take a stab at that .deb next.

[chaoticgoo]

@bpasero you are correct, the bug is not present in Exploration version -- see the two side by side with About info in the screenshot below.

The Exploration version shows the folder's full contents with the exception of the unfollowable symlink, which seems like a fine logical behaviour to me. In my case there is a config.json symlink that a local file manager shows but is not appearing in the VS Code treeview. Fine with me, way better than the version on the left!

[bpasero]

@chaoticgoo great. I think the consequence will be that I will revert that change for our current release and take it in once we go with the version of the exploration build.

[bpasero]

Can anyone confirm this is fixed with our latest insider version (where the reverted change is in)? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[cdancette]

@bpasero I had the same issue (couldn't see any files in a directory mounted with sshfs) and I can confirm it is fixed in this insider build. Thanks !

[bpasero]

Great, setting verified label thereby.