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

201–210 of 423 posts

Re: WSL2 corrupting Git repositories and shell history

#201

Post by alexhutcheson »

pydry wrote: post #109
shawnz wrote: post #103

Earlier quoted context omitted.

I find the opposite, WSL1 is much faster for pretty much every usage except workloads that involve reading/writing lots of files.

The difference on I/O is enough to make WSL unusable. I wasted a day trying to figure out if I had a problem with anti-virus or something that was blocking me before realizing that WSL I/O is just... well, slow. People kept telling me to upgrade to WSL2 to solve that but the version of windows I had didn't allow it. Might have been a blessing in disguise given the data corruption bugs.

What version of Windows doesn’t have WSL2?

Re: WSL2 corrupting Git repositories and shell history

#202

Post by ojnabieoot »

BlueTemplar wrote: post #196
ojnabieoot wrote: post #189

Earlier quoted context omitted.

Calc is really not an adequate substitute for Excel if you need to use VBA macros - which might be coming from your customers! And in the wild I see plenty of older Excel documents (before 97) which I don’t think are compatible with LibreOffice. Obviously this isn’t an ideal situation but historical data around prices/etc from the 90s are often stored as old Excel binaries. In general I think using Calc (or Google Sh…

Calc has several options for languages to use for macros, for instance Python – I'm not certain about VBA support, but it would seem that many industries are slowly migrating to Python anyway : https://news.ycombinator.com/item?id=25588720

The point is that VBA macros are portable across Excel but not between Excel and Calc. Calc does not support VBA macros. As many businesses need to consume spreadsheets with VBA macros, and since porting VBA to Python isn’t sustainable, Calc is simply not a good enough replacement for enterprise.

I am not sure that one anecdotal blogpost supports the idea that industries are moving from Excel to Python. It is more likely that people are productionizing Excel spreadsheets with Python these days, instead of C++ or Java.

Re: WSL2 corrupting Git repositories and shell history

#203

Post by zamalek »

indymike wrote: post #188
zamalek wrote: post #175

Earlier quoted context omitted.

> What am I missing ? Visual Studio. The other thing on my Windows VM is Affinity Photo/Designer (because GIMP is not a realistic Photoshop alternative).

I'd buy affinity designer, photo and publisher again if they ship a Linux version. I have it both for Windows and Mac.

Absolutely, I would too. They are fantastic products.

I did some Googling yesterday and the last word on the matter is that Photo would cost $500k alone, which they couldn't see recuperating.[1]

[1]: https://forum.affinity.serif.com/index.php?/topic/626-affini...

Re: WSL2 corrupting Git repositories and shell history

#204

Post by ConceptJunkie »

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…

> and certainly better than hoary old cygwin.

Say what you want about cygwin, but it never did this.

Re: WSL2 corrupting Git repositories and shell history

#205

Post by Someone »

TylerE wrote: post #185
ylyn wrote: post #177

Earlier quoted context omitted.

This is data loss. A few object files in the Git directory are truncated. Which results in a corrupted repository, from Git's point of view.

That’s corruption. Data loss would indicate an entire fs transaction getting dropped entirely - but not breaking the principle of atomic ops. A write should either happen entirely or not at all.

“A write should either happen entirely or not at all.”

I think many modern file systems try really hard to make that true, but I don’t think you can count on it. “man write” (https://man7.org/linux/man-pages/man2/write.2.html) still says:

“Note that a successful write() may transfer fewer than count bytes”

It also says

“A successful return from write() does not make any guarantee that data has been committed to disk. On some filesystems, including NFS, it does not even guarantee that space has successfully been reserved for the data”

That should be handled by calling fsync, but of course, if that fails, there’s not a lot you can do (even if you exactly know what happened) (https://research.cs.wisc.edu/adsl/Publications/atc20-cuttlef...)

I also don’t think calling data loss due to writes that do not make it to disk “file system corruption” is correct. For file system corruption, the file system data structures have to be overwritten (e.g. the boot record or directory data structures)

Re: WSL2 corrupting Git repositories and shell history

#206

Post by Gibbon1 »

Someone wrote: post #123
harikb wrote: post #30

Earlier quoted context omitted.

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)

Not my area but I seem to remember bitches that Linux lies about fsync. As in it'll swear up and down that it flushed everything to disk, but it's lying.

Also over the years it seems like everyone I've seen that habitually edits files remotely ends up with this sort of pain and butthurt.

Re: WSL2 corrupting Git repositories and shell history

#207

Post by megous »

TylerE wrote: post #185
ylyn wrote: post #177

Earlier quoted context omitted.

This is data loss. A few object files in the Git directory are truncated. Which results in a corrupted repository, from Git's point of view.

That’s corruption. Data loss would indicate an entire fs transaction getting dropped entirely - but not breaking the principle of atomic ops. A write should either happen entirely or not at all.

Corruption is when you write data and you read back different data of the same size. Data loss is when you write data and you read back correct data of the smaller size or nothing.

Not sure what you mean by entire fs transaction. But Linux doesn't have transactional fs interface, so open, write, close can be interrupted at any point with result of just having a new empty file after open, being one of the valid outcomes after crash.

Re: WSL2 corrupting Git repositories and shell history

#208

Post by uranusjr »

ConceptJunkie wrote: post #204
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…

> and certainly better than hoary old cygwin. Say what you want about cygwin, but it never did this.

Parent was talking about WSL1, which didn’t do this either.

Re: WSL2 corrupting Git repositories and shell history

#209

Post by Dylan16807 »

pjmlp wrote: post #51
detaro wrote: post #49

Earlier quoted context omitted.

Because their needs aren't met by developing Windows or macOS software?

Then again why they don't support GNU/Linux vendors?

So if someone installs Linux themselves they don't meet this bar you're setting? That seems pretty far from the normal open source ethos.

Re: WSL2 corrupting Git repositories and shell history

#210

Post by icegreentea2 »

shawnz wrote: post #113
icegreentea2 wrote: post #25

Earlier quoted context omitted.

I use a mix of WSL2, and VMs. WSL2 has a few nice properties for some use cases: a) It comes default with some network binding magic (ok, just configuration) that makes your WSL env almost actually behave like localhost. I know you can configure this yourself, but it's nice out of the box. (on the other hand, sometimes is this exactly the opposite of what you want...) b) My main machine is a bit RAM constrained, and…

Have you tried WSL1? It sounds like it might fit your use cases better: - WSL1 shares the same network interfaces and addresses as the host, no proxying like WSL2 - Significantly less RAM usage - No time sync bug

Oh, I use both =P

I use WSL2 for some docker based projects.

Post reply on HN