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

VSCODE cannot save file launched by WSL 18.04 #50996

Closed
macxfadz opened this Issue Jun 2, 2018 · 14 comments

Comments

Projects
None yet
6 participants
@macxfadz
Copy link

macxfadz commented Jun 2, 2018

Before jumping to the issue let me briefly introduce the environment:

  • VSCode version - 1.23.1 shell 1.7.12 (Win64)

  • Windows x64 version - Windows 10 1803 build 17134.81

  • WSL - Ubuntu 18.04 (as Microsoft store App)

Issue

I launched a C file called "a.c" just for example, and I set AutoSave option in VSCode ,then VSCode launch a the a.c file and I edit as following and also when I press Save following happened too -
vscodesave1

Saying -

Permission denied writing to file (file:///c:/Windows/System32/a.c)

also after that I closed the VSCode from windows side and looking whether at least empty file of "a,c' was created at WSL side ,as permissioned denied I think it wasn't created.But it is created at System32 :( (how can it be ? that's why permission issue exist)

vscodeexit

Please mentioned did I follow a wrong procedure or is this a misuse or expected behavior, also I really need this feature it is very convenient if we have this saving feature.

@macxfadz

This comment has been minimized.

Copy link

macxfadz commented Jun 4, 2018

@joaomoreno Do we have a fix for this right now? or will it be fixed on next release? :)

@joaomoreno joaomoreno assigned bpasero and unassigned joaomoreno Jun 4, 2018

@bpasero

This comment has been minimized.

Copy link
Member

bpasero commented Jun 4, 2018

@macxfadz this is probably an issue with using relative paths, does it work if you use absolute paths instead?

@macxfadz

This comment has been minimized.

Copy link

macxfadz commented Jun 4, 2018

@bpasero
Please note that VSCode installed at Windows 10 not in WSL,As WSL support notepad in windows I thought is support VSCode too.
I can show you the problem with this image.. I think call code with file using absolute path as shown below,
codeempty

the a.c file opend with VSCODE is empty since its path is not valid(not exists in WSL).

@macxfadz macxfadz closed this Jun 4, 2018

@macxfadz macxfadz reopened this Jun 4, 2018

@macxfadz

This comment has been minimized.

Copy link

macxfadz commented Jun 4, 2018

Sorry I pressed accidentally Close and comment button .. apologize! :(

@bpasero

This comment has been minimized.

Copy link
Member

bpasero commented Jun 4, 2018

@macxfadz would you be able to do a little experiment and install node.js? From https://nodejs.org/en/

@macxfadz

This comment has been minimized.

Copy link

macxfadz commented Jun 4, 2018

@bpasero node.js @ windows side right?
Installed node.js on both sides.. but :( no positive result.

@bpasero bpasero assigned bpasero and Tyriar and unassigned bpasero Jun 5, 2018

@bpasero bpasero added this to the June 2018 milestone Jun 5, 2018

@bpasero

This comment has been minimized.

Copy link
Member

bpasero commented Jun 5, 2018

@Tyriar please let me know if this is something on your end to change in the script that starts VS Code. We support a VSCODE_CWD environment variable that - if set - will be used to resolve relative paths against.

@bpasero bpasero removed their assignment Jun 5, 2018

@bpasero bpasero removed the needs more info label Jun 5, 2018

@bpasero bpasero removed this from the June 2018 milestone Jun 5, 2018

@macxfadz

This comment has been minimized.

Copy link

macxfadz commented Jun 5, 2018

@bpasero - What should we follow to fix this issue?

@onomatopellan

This comment has been minimized.

Copy link

onomatopellan commented Jun 5, 2018

That's expected behavior. You shouldnt launch a Windows application from a LxFs (/home/*) folder.

Your PWD must be a DrvFs (/mnt/*) folder (for example /mnt/c/code/C) if you want to call code from WSL.

@macxfadz

This comment has been minimized.

Copy link

macxfadz commented Jun 5, 2018

@onomatopellan why can't we save the file there?

@onomatopellan

This comment has been minimized.

Copy link

onomatopellan commented Jun 5, 2018

@macxfadz Because when you launch code from a Linux folder it opens an empty file on C:\Windows\System32 and you can't save there without being elevated.

Note: If you try to launch a Windows tool, asking it to open a file that is located in your Linux filesystem, it will be unable to open the file (it will appear to be "missing") and Bash will inform you of this problem stating that it was : "Unable to translate current working directory. Using C:\WINDOWS\system32".

This is due to a current limitation in WSL wherein Windows apps should NOT be used to open files in the Linux filesystem. Opening files in the Windows filesystem is fully supported using both Windows apps and Bash/Linux tools (via /mnt//...), but avoid opening Linux files using Windows apps at all cost!

https://blogs.msdn.microsoft.com/commandline/2016/10/19/interop-between-windows-and-bash/

If you just want to open a file with Code Windows version make sure the file it's on a /mnt/* folder.

If you truly need to open a file from a /home/* folder use Code Linux version with a x11 Windows server like you are already doing with gedit.

@Tyriar

This comment has been minimized.

Copy link
Member

Tyriar commented Jun 6, 2018

@bitcrazed any guidance here? It seems like calling code foo from WSL should open <cwd>/foo even though it's the Windows version of VS Code?

@macxfadz

This comment has been minimized.

Copy link

macxfadz commented Jun 6, 2018

@onomatopellan Thank you very much ... very supportive. By the way don't you think is it a bad design? simple WSL able to launch VSCode(Win64 version) but it cannot interact with every file that it has opened !!! yeah I know it's technical barrier.

@bitcrazed

This comment has been minimized.

Copy link

bitcrazed commented Jun 7, 2018

Your WSL Linux distros' filesystems are not accessible from Windows. Thus, when you try to launch VSCode (or any Win32 binary) to load/access a file from, for example, ~/dev/foo/foo.c, the Windows app will essentially respond with "say what now, where and/or what is ~/dev/foo/foo.c?"

And don't try and circumvent this by spelunking through the filesystem, finding where your distro root folders are located and trying to create/modify files directly: HERE BE DRAGONS; you are VERY likely to end up with corrupted files and/or data loss, as described in this still-current post.

We do have tasks on our backlog to address this interop scenario, which will eventually allow Windows apps to seamlessly access and work on/with Linux files, but until we've announced such features, we recommend storing files that you want/need to access via both Windows and Linux tools on your Windows filesystem and accessing them via the /mnt/<drive letter>/path/… interop mount.

@Tyriar Tyriar closed this Sep 12, 2018

@Tyriar Tyriar added the *as-designed label Sep 12, 2018

@vscodebot vscodebot bot locked and limited conversation to collaborators Oct 27, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.