Open bjornfor opened 2 years ago
This is probably because when we install a local extension into remote, we zip the local extension and unzip it on remote. I suspect that while zipping we are also including file modes.
This seems like something a developer who is familiar with the code can fix quickly, right? Or alternatively, any hints as to where that code exists and I can try to fix it myself?
I own this code and if you are interested to contribute the fix, you are welcome and appreciated. Here is the code pointer
Any luck so far? Also hitting this and interested in a fix.
We closed this issue because we don't plan to address it in the foreseeable future. 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!
This is still important to me, please re-open. Without this there is no reproducible and/or offline installation option (AFAIK).
@isidorn: How can a (presumably) trivial fix to chmod +w
some files before changing them be out of scope? I understand it doesn't have high priority for you, but please re-open.
@isidorn Sorry for the noise, but seconding this for visibility. Please reopen. It means that when I use vscode on nixos to access a remote, things are broken when they shouldn't be, and it's not straightforward to fix as a user.
Let's reopen and for now leave on the backlog.
This is my temporary hack until this gets fixed, run this on the server (requires pkgs.inotify-tools
)
#!/usr/bin/env bash
inotifywait -m -q -r -e create --format '%w%f' "$HOME/.vscode-server/extensions" |
while read -r path; do
chmod +w "$path"
done
It is racey, and does not work for extensions with many files, but for small extensions such as nix-ide
it works.
This workaround didn't work for me. I resorted to tarring up my local extensions directory, and extracting it over at .vscode-server/extensions
on the remote, which worked.
What I don't understand is why updateMetadata is trying to write to package.json. Surely it can just leave that file alone? I don't think the solution is to modify the permission bits as they're represented in the zip.
I am hitting this now. If you manage VS Code with Nix you cannot install extensions into a remote SSH VS Code server. I'll try the workaround but I'd love a proper solution.
Does this issue occur when all extensions are disabled?: No. (The issue is about installing extensions on a remote system.)
Steps to Reproduce:
code --extensions-dir /path/to/read-only-tree-of-extensions
. (Why read-only? Because that's how Nix does software deployment. This command just reproduces howvscode-with-extensions
from Nixpkgs works.)Unable to write file '/home/$USER/.vscode-server/extensions/.6661fce6-c826-4679-8f01-8421850781b5/package.json' (EntryWriteLocked (FileSystemError): Error: EACCES: permission denied, open '/home/$USER/.vscode-server/extensions/.6661fce6-c826-4679-8f01-8421850781b5/package.json')
It seems VSCode first copies files from the local system
/path/to/read-only-tree-of-extensions
to~/.vscode-server/
on the remote host and then tries to update~/.vscode-server/extensions/.UUID/package.json
(still on the remote), which fails because the file still has read-only permissions.I tried to chmod the files myself, but it seems VSCode creates a new UUID every time, so it doesn't work.
When copying extensions/files from somewhere to $HOME on a remote machine, with the intention to update some of the files, I think it's reasonable to explicitly set the writeable bit on said files, after the copy operation completes.