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

What should happen when on a read-only filesystem? #148304

Closed
TylerLeonhardt opened this issue Apr 27, 2022 · 4 comments
Closed

What should happen when on a read-only filesystem? #148304

TylerLeonhardt opened this issue Apr 27, 2022 · 4 comments
Assignees
Labels
workbench-editors Managing of editor widgets in workbench window

Comments

@TylerLeonhardt
Copy link
Member

TylerLeonhardt commented Apr 27, 2022

Testing #147706

using an untitled html file:

<a href="/doesnotexit.txt"></a>

image

I think this makes sense because it's trying to save to the root of the file system at /doesnotexist.txt but I wanted to open this anyway just in case because it throws that error and then closes the editor in the background which is maybe not as consistent of this new "error when not exist" flow.

@bpasero bpasero added the *as-designed Described behavior is as designed label Apr 28, 2022
@bpasero
Copy link
Member

bpasero commented Apr 28, 2022

We have no real way to figure out if the

@bpasero bpasero reopened this Apr 28, 2022
@bpasero bpasero added bug Issue identified by VS Code Team member as probable bug workbench-editors Managing of editor widgets in workbench window and removed *as-designed Described behavior is as designed labels Apr 28, 2022
@bpasero bpasero added this to the April 2022 milestone Apr 28, 2022
@bpasero
Copy link
Member

bpasero commented Apr 28, 2022

From no to aye in 5 minutes!

bpasero added a commit that referenced this issue Apr 28, 2022
@bpasero bpasero removed this from the April 2022 milestone Apr 28, 2022
@bpasero bpasero removed bug Issue identified by VS Code Team member as probable bug unreleased Patch has not yet been released in VS Code Insiders labels Apr 28, 2022
@bpasero
Copy link
Member

bpasero commented Apr 28, 2022

Oh, had to revert, not easy to fix: as part of the action flow, the action may decide to open another editor (that actually happens as part of the create file flow). If we await that action, we fail to open that editor because we still think we are in an error case.

So I am actually proceeding in the background to open the place holder without waiting for the action to finish and thus I cannot detect whether the action results in an error or not. As such, I simply always consider the action to have succeeded in a way that I do not need to show the place holder:

const result = errorAction.run();
if (result instanceof Promise) {
result.catch(error => this.dialogService.show(Severity.Error, toErrorMessage(error)));
}
errorHandled = true; // consider the error as handled!

tl;dr;: if you press any button in the dialog other than "Cancel", no place holder shows because I assume you have dealt with the error, even if that fails.

aeschli pushed a commit that referenced this issue May 2, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Jun 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
workbench-editors Managing of editor widgets in workbench window
Projects
None yet
Development

No branches or pull requests

3 participants
@bpasero @TylerLeonhardt and others