Explorer: root folder that is a symbolic link not decorated

[bpasero]

Steps to Reproduce:

1. ln -s source target to create a link on a folder
2. add the link as single entry to a workspace config file
3. open that workspace
4. restart

=> I see no link decoration for the root folder

[isidorn]

Well it is not only the symbolic link decoration but also the title of the resource.
For root resources I see the title of the target, for all other resources I see the title of the source.

It seems we are resolving roots in some other way compared to other resources.

After some investigation it seems that the issue comes from the contextService.getWorkspace().folders which gives the uri of the target not of the source.
Thus my explorer model is never aware that the root was actually link, since I get the uri resolved already here

Also assigning to @bpasero and @sandy081 since you might now if this is expected from the context service

[bpasero]

@isidorn @sandy081 I am quite sure that we are not realpath any of the root folders. We (should) only do that when you open a single folder, but maybe that changed?

[isidorn]

@bpasero well that is what I am seeing, just put a breakpoint here on startup in a multi folder workspace

[bpasero]

@isidorn but this issue is about multi-root workspace, sorry if I did not make this clear.

=>

[isidorn]

@bpasero that is what I meant. I was not clear sorry. So have a workspace, in that workspace have any number of folders I am getting the realpath from the contextService for each root

[bpasero]

@isidorn ok let me check...

[bpasero]

As discussed, you need to add the link to the file manually, not going through a picker.

[isidorn]

@bpasero good catch. The issue was that I forgot to update the explorerItem merge method to respect isSymbolicLink

[bpasero]

@isidorn there still seems to be a case where this does not work:

[isidorn]

@bpasero the issue with that corner case is timing.
I first get the event that workspaceRoots changes, the decorations update, and only then is the fileStat actually merged and I have data that it is a symbolicLink.

A proper fix would be for the DecorationProvider to also listen on whenever a file gets resolved to update decorations. Feels like overkill.
A hack is to react on workspace folder change event with a timeout.

I do not like both solutions so to the backlog. Open for suggestions

[vscodebot]

This iteration we focus on issue grooming. This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!