[windows] [open workspace] can't read the content of "C"

[marcdumais-work]

I can successfully select/open a workspace if it's located under /c/users/. But if I try to go up a directory, it seems that we're enable to read the files under /c/.

[kittaakos]

Still same as: #631

[kittaakos]

Ohh, sorry for the confusion, the other task is closed too. I have just put it there for future references. I am reopening this.

[hexa00]

Seems like it's not a duplicate?

[kittaakos]

Seems like it is.

[hexa00]

Could also be related to #199

[hexa00]

I just retested this and it's still an issue.

[marcdumais-work]

Since this issue is the one that remained open, I tagged #631 as being the duplicate, and removed the tag from this one here

[westbury]

This problem is caused by a confusion between the meanings of "c:" and "c:". When getting the directory listing for c:, it is passing a uri of file:///c%3A which is converted to "c:" by FileUri.fsPath. That is probably wrong and it should convert to "c:". The call to fs.readdir, when passed "c:", correctly returns a listing of the default directory, not the root directory. When these files are appended to the original uri, we get files that don't exist so they are removed from the list. Result: nothing in the list.

The conversion of file:///c%3A to c: is done by the vscode-uri module (see Uri.parse function). One might argue that the vscode-uri module is wrong but I suspect that we would get push-back if we tried to modify vscode-uri. The best place to fix this is probably in FileUri.fsPath. I'll submit a PR shortly.

[westbury]

Ha ha, it seems Github have decided to remove the backslashes from C : \ in the previous comment. I am sure you can figure out where backslashes followed c: in the comment.

[kittaakos]

Fixed with #3419.