Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WSL2 corrupting Git repositories and shell history

github.com

Post reply on HN
Print view View original

61–70 of 423 posts

Re: WSL2 corrupting Git repositories and shell history

#61

Post by bmurphy1976 »

tremon wrote: post #22
tutfbhuf wrote: post #4

Earlier quoted context omitted.

But why? WSL1 was something like wine but reverse, but WSL2 is actually linux.

The problem is likely not in the Ext4 code, but in the block I/O driver (which is Hyper-V specific, IIRC) or even in Hyper-V itself. Several reports mention Windows shutdowns, sleep or hibernation, so it may be a simple unclean shutdown of the VM. A bigger problem would be if Hyper-V is either ignoring memory barriers, or caching writes to the disk and losing them when the Hyper-V service is shutdown. But that would…

Huh, interesting. I run a variety of linux based services at home. For years I ran them on a Hyper-V VM (because my computer was technically my gaming machine). I only recently migrated everything to a cluster of Raspberry Pi devices.

I used to have occasional problems with this setup, and it was always some kind of drive corruption or mounting issue. I wonder if this is related?

Re: WSL2 corrupting Git repositories and shell history

#62

Post by CJefferson »

bserge wrote: post #3

I don't really understand the use case for WSL. What are the advantages? You could run a full Linux VM and do everything on it on any machine these days. Which is what I do, but I'm just an old school hack. Anyone who uses WSL care to enlighten me? Thanks!

WSL2 is "just a full Linux VM", just easy to install and integrated nicely with other parts of the OS

Re: WSL2 corrupting Git repositories and shell history

#63

Post by pram »

pjmlp wrote: post #46
jevgeni wrote: post #24

Earlier quoted context omitted.

Or, alternatively, a crowd whose needs aren’t completely met by Linux.

Then why they develop GNU/Linux software to start with?

People might get paid money to develop (proprietary!) software that deploys to Linux. That doesn't mean they enjoy using Linux.

Re: WSL2 corrupting Git repositories and shell history

#64

Post by sam_lowry_ »

umvi wrote: post #9
bserge wrote: post #3

I don't really understand the use case for WSL. What are the advantages? You could run a full Linux VM and do everything on it on any machine these days. Which is what I do, but I'm just an old school hack. Anyone who uses WSL care to enlighten me? Thanks!

When I launch my WSL2 Ubuntu shell, I have a CLI prompt in Getting that same quality of experience under VirtualBox was nightmarish. Longer boot times, shared clipboard/filesystems were always breaking, random stuff related to hardening made update difficult.

>Clipboard works perfectly

Which one? Secondary? And the primary does not work at all?

Re: WSL2 corrupting Git repositories and shell history

#65

Post by tyingq »

tarr11 wrote: post #42
crispyambulance wrote: post #23

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…

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?

There's examples of people using the Linux filesystem and having the issue.

From reading the issue and related ones, it sounds like it might be related to some sort of unpredictable unclean VM shutdown.

Re: WSL2 corrupting Git repositories and shell history

#66

Post by h_r »

proactivesvcs wrote: post #39
temac wrote: post #20

Earlier quoted context omitted.

> Running a virtual machine often means accessing the UEFI to be sure they have virtualization extensions enabled. Likewise for WSL2. I hope modern computers with a capable processor are all shipped with virtualization enable at firmware level, because Hyper-V can be used for tons of things in recent Windows.

Enabling hardware virtualisation opens up a significant and deep attack surface. Considering the vanishingly small percentage of users which benefit from it, I hope it stays off by default.

Are there significant risks from running virtualization locally like this? If so, can you provide any links or elaborate a bit so I can follow up? Most of what I've seen on such vulnerabilities refer to server infrastructure.

Re: WSL2 corrupting Git repositories and shell history

#67

Post by pram »

nijave wrote: post #45
bserge wrote: post #3

I don't really understand the use case for WSL. What are the advantages? You could run a full Linux VM and do everything on it on any machine these days. Which is what I do, but I'm just an old school hack. Anyone who uses WSL care to enlighten me? Thanks!

Business. For better or worse, there are plenty of places where the policy and tech allow WSL but installing a hypervisor on your machine is much more challenging. WSL2 is basically just a Linux VM, though (I think it actually uses Hyper-V containers which seem to occupy some weird space between Linux container and VMs)

Hyper-V is VMs not containers. When you enable Hyper-V it's actually the 'operating system' and Windows is a guest VM believe it or not.

Re: WSL2 corrupting Git repositories and shell history

#68

Post by dmw_ng »

harikb wrote: post #30
crispyambulance wrote: post #23

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”

Reminds me of an infuriating old bug in VirtualBox where it wouldn't notice the size of a file had changed. Devs were working in some Windows editor then using Git within VirtualBox to commit changes, resulting in inexplicable trailing nulls and garbage turning up in the repo

Took quite some time to figure out what was causing it. "Everyone is somehow corrupting files except for me, wtf?" Magic filesystem translation layers always suck

Re: WSL2 corrupting Git repositories and shell history

#69

Post by hvdijk »

crispyambulance wrote: post #23

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…

I don't think calling it WSL2 was a mistake. It wasn't something that was good for the users, but it had a very clear benefit for the people working on WSL: calling it WSL2 allowed them to close WSL1 issues en masse as "fixed in WSL2" and never look at them again.

Re: WSL2 corrupting Git repositories and shell history

#70

Post by lukeschlather »

crispyambulance wrote: post #23

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…

Cygwin was fast and mostly just worked. I did not find WSL to work well, WSL2 seems more usable. Still has warts but definitely an improvement.
Post reply on HN