Hacker News Reader

Comment by JiNCMG | Hacker News Reader

If you gonna do dev on WSL then make sure all of it is on Linux. Don't mix and match.

They still haven't corrected the SEVERE disk read speed when accessing a Windows directory. For example, if you use zsh/Oh-My-Zsh and have any of the themes setup that pulls git info for the prompt (over 99% of them do this), cd into a git repo on your Windows side: cd /mnt/c/repos/example_git and expect a minimum of a 1 minute wait for simple repos.

The WSL IP Address changes on every restart.... ALWAYS. So trying to setup a local web server for testing becomes a hassle.

View on HN

> The WSL IP Address changes on every restart.... ALWAYS. So trying to setup a local web server for testing becomes a hassle.

This should only be true if you're doing funny network stuff. On my machine, exposing WSL2 with 127.0.0.1:8080 allows me to connect on my Windows browser: https://i.judge.sh/shocked/Punch/WindowsTerminal_whYLqVLsIM....

That's wierd. Any server I run on wsl side can be accessed via localhost from Windows side. Been like this since the beginning of wsl if I'm not mistaken.

One issue that I've run into is that if you only bind to IPv6 in WSL, then you will only be able to access the service using IPv6 on the Windows side (i.e. ::1 works, but 127.0.0.1 doesn't). OSs usually automatically bind to IPv4 whenever you bind to IPv6, but that's not the case with WSL (actually, it does bind to both, but only inside WSL, not on the Windows end). Lots of programs (like node) bind to IPv6 by default, so this can catch people off guard and they wonder why 127.0.0.1 or localhost isn't working.

Here's the github issue about it: https://github.com/microsoft/WSL/issues/4851

>They still haven't corrected the SEVERE disk read speed when accessing a Windows directory.

I got this when I tried to npm install a project and it was taking forever.

https://stackoverflow.com/a/68974497/3983822

unfortunately there's fundamental issues with file operations on NT:

* you can't delete an opened file, which means every folder delete/move operation has to enumerate all descendents to acquire exclusive locks.

* every file operation goes through a filter driver (think virus scanners)

* the kernel parses path names, and (I think) maybe dispatches one operation per path element.

all of the above can't be fixed due to compatibility apparently. that's why WSL2 moved off of NTFS.

> cd into a git repo on your Windows side: cd /mnt/c/repos/example_git and expect a minimum of a 1 minute wait for simple repos.

Yes that will be slow, don’t use /mnt, anything under that directly will crawl. Use /home or somewhere else and save your work there. In VSCode you can access any dir and now there’s gui support so there’s no excuse to be using /mnt now. I believe some docs on WSL do tell you this

> The WSL IP Address changes on every restart.... ALWAYS. So trying to setup a local web server for testing becomes a hassle.

That’s weird, I’ve never had any issues relating to running a web server. Listening on a port in WSL automatically exposes it on Windows. I’ve not had to configure anything when restarting etc.

I occasionally run into an issue that breaks localhost port forwarding. I can access the service that's running inside WSL2 via its actual IP (172.#.#.#) when 127.0.0.1 breaks. But that IP address changes every time WSL instance restarts.

I've had to set up a scheduled task[0] to update an entry in my hosts file every time WSL is assigned a new IP address, which works well enough.

[0]: https://abdus.dev/posts/fixing-wsl2-localhost-access-issue/

Excuse my ignorance here but why are you using its actual IP instead of just localhost or 127.0.0.1? When starting up a local server inside of WSL I’ve never needed to do that (unless it needs to be accessed somewhere else in the network)

I know the blog post says localhost redirection “often fails” but that’s just never been the case for me, and the citation it uses is just a link to the WSL issues page rather than a specific issue.

Localhost mostly works, and I use localhost when it does work. But when it fails (once a week or so, and this keeps happening on 3 different machines running the latest/a recent Insider build), usually after the PC wakes up from sleep, I have to restart the PC to access via localhost again, which is undesirable for me because I have to spend 10 min restoring all apps & windows back to how they were.

Or I can use the IP address directly and map it to a friendly hostname, in my case `wsl` and keep working. This is done behind the scenes with a scheduled task, so when I see `localhost:PORT` doesn't work, I just retry it with `wsl:PORT`.

The reason I haven't linked to a specific issue is that there's just so many [*], and localhost sharing is still buggy and hasn't been fixed even after 2 years.

[0]: https://github.com/microsoft/WSL/issues/5298

[1]: https://github.com/microsoft/WSL/issues/7492

[2]: https://github.com/microsoft/WSL/issues/6725

[3]: https://github.com/microsoft/WSL/issues/4885

[4]: https://github.com/microsoft/WSL/issues/5439

and many more.

Fair enough, hopefully that gets fixed, my machine doesn’t go to sleep that often so maybe that’s why I haven’t been affected. My servers are not usually long-running, I only use them when developing so that’s probably why.

For future reference linking to the issues page when there’s over 1.2k issues is unhelpful to the reader, you’re better off putting that list into your blog post, or just pick one that’s the most useful like https://github.com/microsoft/WSL/issues/7492. I doubt the reader is going to trawl for every single issue to find the ones you’re talking about. It’s like saying “Google it yourself”.

When I had linked it in August 2020, it mostly had results for issues related to localhost forwarding, so it made sense at the time. But linking a live search wasn't the best choice, I agree.

I think linking to a specific issue is more useful, like you say. I'll update the post.

> It’s like saying “Google it yourself”.

Funny enough, almost all traffic is from organic searches :)

Yeah this is an annoying bug. It seems related to resuming from sleep. For WSL 2 one workaround is to just restart WSL; you're effectively rebooting the VM.

`localhost` always resolves both machines without issue, it’s when you hard code 127.0.0.1 or ::1 instead of localhost, you end up with shenanigans.

I do all my dev on Windows side and I use WSL from time to time to quickly test builds.

Could you get mDNS setup?

Reply on news.ycombinator.com