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.

Sign up for GitHub

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

Jump to bottom

Workspace UI storage not picked up when launching workspace with different casing #1162

Closed
bpasero opened this issue Dec 10, 2015 · 5 comments
Closed

Workspace UI storage not picked up when launching workspace with different casing #1162

bpasero opened this issue Dec 10, 2015 · 5 comments
Assignees
@bpasero
Labels
bug Issue identified by VS Code Team member as probable bug *duplicate Issue identified as a duplicate of another issue(s)
Milestone
Backlog

Comments

@bpasero
Copy link
Member

bpasero commented Dec 10, 2015

Currently we loose all workspace associated state when the workspace path is using different casing. Ideally the storage is agnostic to casing for file systems that are case insensitive.
@bpasero bpasero added the bug Issue identified by VS Code Team member as probable bug label Dec 10, 2015
@bpasero bpasero self-assigned this Dec 10, 2015
@bpasero bpasero added this to the Backlog milestone Dec 10, 2015
@bpasero bpasero mentioned this issue Dec 10, 2015
Closed
@bpasero bpasero modified the milestones: Jan 2016, Backlog Dec 17, 2015
@bpasero
Copy link
Member Author

bpasero commented Dec 18, 2015

There is still an issue with how we handle files in the workbench: Since the workbench is treating files with different casing as individual files, you end up having potentially the same file open twice. The road to solve this is to make the workbench fully agnostic of file path casing which is a larger task.

@bpasero bpasero changed the title Workspace storage should be case insensitive on Mac/Windows Workspace storage should be workspace path case-insensitive on Mac/Windows Dec 18, 2015
@bpasero bpasero added feature-request Request for new features or functionality workbench and removed bug Issue identified by VS Code Team member as probable bug labels Dec 22, 2015
@bpasero bpasero removed their assignment Dec 22, 2015
@bpasero bpasero self-assigned this Mar 30, 2016
@bpasero bpasero modified the milestones: July 2016, Backlog Jul 2, 2016
@bpasero bpasero modified the milestones: July 2016, Backlog Jul 6, 2016
@bpasero
Copy link
Member Author

bpasero commented Jul 6, 2016

With the update to Electron 1.2.6, fs.realPath now returns the right casing so this issue should not happen anymore.

@bpasero bpasero closed this as completed Jul 6, 2016
@bpasero bpasero reopened this Jul 8, 2016
@bpasero bpasero modified the milestones: August 2016, July 2016, Backlog Jul 8, 2016
@bpasero bpasero removed this from the August 2016 milestone Jul 9, 2016
@bpasero bpasero added the upstream Issue identified as 'upstream' component related (exists outside of VS Code) label Jul 9, 2016
@bpasero bpasero removed their assignment Aug 17, 2016
@bpasero bpasero modified the milestones: September 2016, Backlog Sep 17, 2016
@bpasero
Copy link
Member Author

bpasero commented Sep 19, 2016

This landed. To verify: start VS Code from the command line 2 times after each other, once from a directory that has the real casing as it is on disk and once with different casing. In both cases you should get the view state restored from the first launch, even though the paths are different.

@bpasero bpasero closed this as completed Sep 19, 2016
@bpasero bpasero added bug Issue identified by VS Code Team member as probable bug and removed feature-request Request for new features or functionality labels Sep 19, 2016
@bpasero bpasero changed the title Workspace storage should be workspace path case-insensitive on Mac/Windows Workspace UI storage not picked up when launching workspace with different casing Sep 19, 2016
@bpasero bpasero self-assigned this Sep 19, 2016
@bpasero
Copy link
Member Author

bpasero commented Sep 22, 2016

Reopening because it looks like node.js 6.4.0 will revert the nice fs.realpath to go back to the previous JS implementation and behaviour.

@bpasero bpasero reopened this Sep 22, 2016
@bpasero bpasero modified the milestones: Backlog, September 2016 Sep 22, 2016
@bpasero bpasero removed electron-update upstream Issue identified as 'upstream' component related (exists outside of VS Code) labels Sep 22, 2016
@bpasero bpasero mentioned this issue Sep 22, 2016
Closed
2 tasks
@bpasero
Copy link
Member Author

bpasero commented Sep 22, 2016

Merging into #12448

@bpasero bpasero closed this as completed Sep 22, 2016
@bpasero bpasero added the *duplicate Issue identified as a duplicate of another issue(s) label Sep 22, 2016
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bpasero bpasero

Labels
bug Issue identified by VS Code Team member as probable bug *duplicate Issue identified as a duplicate of another issue(s)
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
1 participant
@bpasero