Readonly workspace folders

[isidorn]

• add API that a FileSystemProvider can be readonly
• open readonly files using readonly editors
• disable all context menu commands in the explorer which do not make sense on a readonly resource
• disable all actions (explorer title) that do not make sense on a readonly resource

[IlyaBiryukov]

What granularity is this read-only support going to be? Per workspace, per root, or per file?
There is a feature request for file-level read-onliness, #17670

How about other actions that can potentially mutate user state? Like find-and-replace or code actions?
Is debugging in scope?

Extensions should be able to contribute to how VS Code detects read only status of files. FileSystemProvider is a good place where it could query if a given file (or the whole file system) is read-only.

[isidorn]

@IlyaBiryukov the read only will be per FileSystemProvider - which in practice means per root. Thus each file in that root will be read only. And extensions will be able to contribute this when they register a FileSystemProvider.

As for various actions we will try to support this property in as many places as possible - however this is currently work in progress.

[isidorn]

We have done what we have planned for this milestone -> closing.
If there are subsequent feature requests we can treat them in new issues.

@IlyaBiryukov you can try it out in tomorrow's insiders

[IlyaBiryukov]

@isidorn How a file system provider can change its read-only state once it has been opened by VSCode? The scenario is when read-only limit is lifted or imposed mid session.

[isidorn]

@IlyaBiryukov he can re-register

[IlyaBiryukov]

I tried that and didn't see any effect (the file system provider was in use when I disposed the old one and registered the new one). How can I re-register it when VSCode has already opened a work space that uses this scheme?

[IlyaBiryukov]

@isidorn, In particular, open documents tend to stick with read-only status they were opened with. If underlying file system provider changes, open documents do not change their read-only status, and there is no way to tell them do that. Even if I close and re-open them, they do not update their read-only status.

[IlyaBiryukov]

Other issue I see is that when an extension applies edits to the documents opened from a read-only file provider, the document becomes marked as 'dirty' but saving it always fails with an error "Failed to save 'bar.js': Insufficient permissions. Select 'Retry as Admin' to retry as administrator.", retrying as administrator does nothing and repeats the error.

[isidorn]

@IlyaBiryukov thanks for the feedback. This milestone we have done the initial work for the readonly workspaces, dynamic registration is possible in theory but in practice there are limitations as you have noticed. The current issue is that once a file is resolved and it is readonly it will not change.

Thus as a workaround for now I suggest that your extension after re-registering a file system provider forces an explorer refresh by executing this command
workbench.files.action.refreshFilesExplorer

Also please create seperate issues and ping me on them regarding other issues you hit.
Thanks a lot

[IlyaBiryukov]

workbench.files.action.refreshFilesExplorer command did not help.

Here are the issues:
#53256, #53257