- WSL2 sometime corrupt .zsh_history and git https://github.com/microsoft/WSL/issues/5026
- WSL2 corrupts ext4 filesystem https://github.com/microsoft/WSL/issues/5895
- WSL2 sometime corrupt .zsh_history and git https://github.com/microsoft/WSL/issues/5026
- WSL2 corrupts ext4 filesystem https://github.com/microsoft/WSL/issues/5895
From what I’ve seen it’s a combination of the storage drivers and the storage virtualisation in HyperV rather than a specific issue. I imagine it’s something similar in WSL.
I really don’t trust it as a platform at all. It’s barely better with windows guests.
I think you’ve hit the nail on the head there. It seems like every organisation I’ve been part of which has a significant Windows presence is either static or planning a rollout of and migration to some new magical enterprise software that replaces the old enterprise software they purchased and this time it’ll definitely make everything better. It’s amazing to me how much money gets spent on per-seat licensing for what essentially amounts to no noticeable improvement for anyone involved. But sure, I’m sure this company-wide spyware of choice will be the one that finally means we can just stop caring about security or provisioning machines, right folks?
It’s like the folks doing it have mastered the art of finding busywork that’s just complicated enough that folks signing the cheques can’t really tell they’re burning money. In that sense it’s beautiful I suppose.
Just, erm, ignore the fact a dozen different developers have essentially root access to production databases... at least they can’t install software!
I mean a bash script that handles no errors and outputs nothing just screams madness. The same thing wrapped in a .MSI .. well, you'll never know what hit your, and if it's your job to somehow unfuck this, it's virtually a piece of literal hell itself, slowly rotting and eroding people's soul and mind.
I have so much respect for them.
Best option is still vbox and putty IMHO. VScode will work with it and SSH fine.
Or say fuck it, buy a Mac and do all your Linux work in the cloud.
What are you talking about, that is how you diagnose a Windows box...
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 likely affect more than just WSL, so we'd have seen the problem sooner (or so I vehemently hope).
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?
I assumed that had all been fixed by now, but yeah, these things can get tricky fast.
[1]: https://lwn.net/Articles/322823/
[2]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/...
as far as I know when wsl2 is actiavted, hyper-v runs as type-1 and linux, windows are virtual after activating it.
thus if it crashes, you get a bsod
WSL2 being Linux means that, unlike WSL1 which directly uses the host NTFS filesystem, it's probably using an emulated block device to hold its filesystem. If that emulated block device doesn't correctly honor write barrier requests from the Linux kernel, it could explain the corruption.
* the kernel is not properly shutdown (and sometimes some buffers are not flushed)
* the virtual block device and/or its linux driver has bugs