Live data from Hacker News

WSL2 corrupting Git repositories and shell history

github.com

121–130 of 423 posts

Re: WSL2 corrupting Git repositories and shell history

#121
post #42

Earlier quoted context omitted.

Huh, I had the opposite experience trying to use wsl1 with a rails app, which required lots of workarounds. Postgres never worked for example natively. Several npm modules would fail when running webpack. wsl2 worked perfectly for these cases. I wonder if people are mounting an ntfs volume in wsl2 which is really slow and janky?

I develop Rails in WSL1 just fine. > Postgres never worked for example natively. That's a minor incovenience at worst. I will stay put in WSL1. If I wished a VM I would have just installed VMWare and run some Linux ISO image from it.

> That's a minor incovenience at worst.

What a bizarre claim. It's irrelevant if you don't need Postgres, a minor inconvenience if you can easily adopt a workaround, and a show stopper if you were relying on accessing a local Postgres instance.

Re: WSL2 corrupting Git repositories and shell history

#122

I only see 1 user confirming it and he had a special or odd disk setup (merged disks which also do not show as merged, might be the source of the problem). Is this confirmed by anyone else?

Huh? skhaz, 2n3906, PulsarFox, Annih, Champkinz, sidharthramesh, mbrumlow, luigimannoni, and jmfury all confirm the problem in the linked GitHub issue.

Re: WSL2 corrupting Git repositories and shell history

#123
post #30

I think calling it WSL2 was a mistake. The predecessor, WSL, "just worked" and it was more a less a linux experience for most practical purposes-- and certainly better than hoary old cygwin. This caused a lot of people to believe they could just transition to WSL2, lead on by the promise of an even more performant linux experience. The documentation didn't say anything about complications from attempting this, so a l…

File system corruption is unforgivable mistake, but FS work is really hard to get right. Even stuff like VMware corrupts shared folders ... wherever they try to bypass a driver translation layer. Just Google for “vmware shared folder corruption”

Is this file system corruption? The article isn’t 100% clear it ‘only’ loses some data writes, but it also doesn’t explicitly say files not being written are affected, directory structures are corrupted, etc.

So, to me, it looks like WSL2 not completely flushing writes to the underlying file system. Bad, but not as bad as file system corruption (which could lead to losing all data on the disk)

Re: WSL2 corrupting Git repositories and shell history

#124

> Feel like booting Linux on a separate disk because of these issues. It always seemed strange to me that people would rather use WSL than the real thing when Windows doesn't bring much advantage. What am I missing ?

Linux support for touchscreen is measly, and it's a really nice feature of many Windows laptops. IMO Windows GUI has the best out-of-box features, OSX second and Linux third. Now, if you like working from the terminal, that order is reversed.

Re: WSL2 corrupting Git repositories and shell history

#125

> Feel like booting Linux on a separate disk because of these issues. It always seemed strange to me that people would rather use WSL than the real thing when Windows doesn't bring much advantage. What am I missing ?

> It always seemed strange to me that people would rather use WSL than the real thing when Windows doesn't bring much advantage. Windows brings lots of advantage to some things (including interfacing with the large number of people who rely on people having software that works only or best on Windows; in anything other than very tech-focussed firms this probably includes your employer, and even in such firms it often…

My team has to support both windows and Linux builds of our product. WSL1 was a godsend for this - I no longer had to ssh into a VM and could build both the Linux and windows versions from the same source, which was amazing. I hit one issue with wsl2 and then I reverted because I learned that this scenario (different builds from same source) would always be slower on wsl2.

Re: WSL2 corrupting Git repositories and shell history

#126
post #76

Earlier quoted context omitted.

You can say "fixed in " regardless if the name is numerically sequential.

True, but if MS hadn't presented WSL2 as a variant of WSL, any issues fixed in WSL2 wouldn't count as fixed in the WSL issue tracker. I would prefer it if their issue tracker marked these, more honestly in my opinion, as "This issue is will not be fixed in WSL, you can migrate to HVL instead" (using HVL as a hypothetical name for WSL2) with a separate HVL issue tracker.

I guess I don't follow your point. The very reason WSL2 exists is because there were countless issues that COULDN'T be fixed with the way WSL1 was implemented. Why would they leave an issue open they fixed, just because the fix required a complete re-implementation? Furthermore why would they change the name, this is literally how they are carrying forward the functionality of WSL 1. It's still Linux on Windows, there is still a custom subsystem to allow the functionality. It is quite literally still Windows Subsystem for Linux. As documented:

https://i.redd.it/po98dksksjx21.png

Should Mac Office not be called Office because they completely re-wrote it?

Re: WSL2 corrupting Git repositories and shell history

#127
post #35

MS is ridiculous, corrupting the filesystem is an OS mistake of the first order. Any systems developer should view corruption of a persistent storage system of any kind as totally unacceptable. And in this case the whole filesystem is open source! Meanwhile the open source people built a decent NTFS driver for linux years ago, I haven't seen what specs are released but I assume they needed to fill a few doc gaps to m…

Yes, let's pretend that the 4.19 EXT4 corruption issue in 2018 never happened.

No need to pretend, because it never happened:

> Initially, the problem was thought to be in the ext4 filesystem, since that is what the affected users were using...It took until December 4 for Lukáš Krejčí to correctly bisect the problem down to a block-layer change.

https://lwn.net/Articles/774440/

Re: WSL2 corrupting Git repositories and shell history

#128
post #87
post #71

Earlier quoted context omitted.

One reason might be, is that they might need to in part work with a server-side system that runs on Linux and it’s easier this way. But maybe they also need to work with stuff thats Windows only. Say they need to produce media assets with the Adobe suite. Not everything is vimmable.

SSH and X Windows servers also exist for Windows.

It takes me 2 minutes to install WSL Ubuntu. Or I could spend half a day on figuring out a hacky solution to a Windows/SSH/XWindows workflow that offers even a comparable level of integration. It will grow into weeks of obsessive tweaking until I feel compelled to write a blog post for HN where I show my sick setup and hours and hours I dumped into this, while meaningful work piled up in my TODOs.

... Or I could just install WSL.

Re: WSL2 corrupting Git repositories and shell history

#129

> Feel like booting Linux on a separate disk because of these issues. It always seemed strange to me that people would rather use WSL than the real thing when Windows doesn't bring much advantage. What am I missing ?

> What am I missing

Being able to use both at the same time. Being able to open windows apps, and have them use the linux filesystem and executables (like IDEs)

Post reply on HN