Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FSProvider: dependency on hierarchical paths? #35135

Closed
joaomoreno opened this issue Sep 26, 2017 · 7 comments
Closed

FSProvider: dependency on hierarchical paths? #35135

joaomoreno opened this issue Sep 26, 2017 · 7 comments
Assignees
Labels
*question Issue represents a question, should be posted to StackOverflow (VS Code) remote Remote system operations issues

Comments

@joaomoreno
Copy link
Member

Testing #35009

Maybe the Explorer has a requirement on hierarchical resources having hierarchical URIs...

@jrieken
Copy link
Member

jrieken commented Sep 27, 2017

No clue, @isidorn @bpasero What defined the structure of the explorer model? The hierarchical stat model, or uri-path-math, or both?

@jrieken jrieken added info-needed Issue requires more information from poster remote Remote system operations issues labels Sep 27, 2017
@isidorn
Copy link
Contributor

isidorn commented Sep 27, 2017

Getting children in the explorer is done by resolving the file here
Also getting the parent we usualy do stat.parent and try not to do any path smartness.
AFAIK we have no dependency on hierarchical paths, though there are probably some assumptions regarding the hierarchy hidden somewhere.

@bpasero
Copy link
Member

bpasero commented Sep 27, 2017

@jrieken didn't you say at one point that we expect extension authors to return URIs that follow a disk scheme, e.g. there is hierarchy reflected in the URI. In other words, we would not expect URIs such as: scheme://myserver.something/?resolve=something

Anyway, we do expect a hierarchy in all our calls to isParent where we want to find out if one path is a parent of another. So yes, this expectation drags through our system....

@jrieken
Copy link
Member

jrieken commented Sep 27, 2017

@jrieken didn't you say at one point that we expect extension authors to return URIs that follow a disk scheme, e.g. there is hierarchy reflected in the URI. In other words, we would not expect URIs such as: scheme://myserver.something/?resolve=something

Well, yes and "hello, here comes reality" maybe no. One problem was that we were not able to get @joaomoreno's stats to show in the explorer and we were clueless why... So one guess was that the explorer depends on hierarchal paths. It's not clear if all providers can full-fill the requirement of such paths but it is valuable to know that we will have a hard time without them

@joaomoreno
Copy link
Member Author

joaomoreno commented Sep 27, 2017

In my example, my URIs didn't represent the hierarchy the actual underlying model had. A parent's URI was not a prefix to all its children's URIs.

@vscodebot vscodebot bot closed this as completed Oct 4, 2017
@vscodebot
Copy link

vscodebot bot commented Oct 4, 2017

This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our guidelines for filing issues. Thank you for your contributions.

@jrieken jrieken reopened this Oct 4, 2017
@jrieken jrieken removed the info-needed Issue requires more information from poster label Oct 4, 2017
@jrieken jrieken added the *question Issue represents a question, should be posted to StackOverflow (VS Code) label Nov 13, 2017
@jrieken
Copy link
Member

jrieken commented Nov 13, 2017

Closing as question, the answer seems to be "Yes, we depend on hierarchical uris..."

@jrieken jrieken closed this as completed Nov 13, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Dec 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
*question Issue represents a question, should be posted to StackOverflow (VS Code) remote Remote system operations issues
Projects
None yet
Development

No branches or pull requests

4 participants