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

WSL starting directory not Linux home for fresh WSL instance #10704

Closed
ednl opened this issue Jul 19, 2021 · 2 comments
Closed

WSL starting directory not Linux home for fresh WSL instance #10704

ednl opened this issue Jul 19, 2021 · 2 comments
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@ednl
Copy link

ednl commented Jul 19, 2021

Windows Terminal version (or Windows build number)

1.8.1521.0

Other Software

  • Windows 10 Pro (21H1, 19043.1147)
  • Ubuntu-20.04 (Linux amd 5.4.72-microsoft-standard-WSL2 # 1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)

Steps to reproduce

Ubuntu-20.04 is the default distro. Windows Terminal is set to start up at boot. Settings:

  • Command Line = wsl.exe -d Ubuntu-20.04
  • Starting Directory = //wsl$/Ubuntu-20.04/home/username

Expected Behavior

Ubuntu WSL starts up in the Linux home directory ~ (= /home/username)

Actual Behavior

For fresh WSL instances, Ubuntu WSL starts up in the Windows home directory: /mnt/c/Users/username

This is true for every WSL instance in Windows Terminal at boot, and every other time it has to start a fresh WSL instance (after closing it and waiting a while until the WSL instance is killed). When the WSL instance is already running, it does work as expected. I do not see a way to always start up WSL in the Linux home directory. This is especially important since WSL2 and its greater performance difference between Linux and Windows file systems.

There have been numerous issues regarding the Starting Directory that have now all been closed. I cannot find a reference to this specific issue, though: that it would be a bug or unexpected result to not have the //wsl$ path available for fresh WSL instances. I think it is. It is definitely unexpected to me. There is one comment describing the behaviour: #592 (comment)

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jul 19, 2021
@zadjii-msft
Copy link
Member

Thanks for the report! This is actually already being tracked by another issue on our repo - please refer to #7197 for more discussion.

/dup #7197

@ghost
Copy link

ghost commented Jul 19, 2021

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost closed this as completed Jul 19, 2021
@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jul 19, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

2 participants