On Mon, Apr 18 2022, brian m. carlson wrote: > [[PGP Signed Part:Undecided]] > Hey, > > On 2022-04-18 at 07:47:07, Attila Csosz wrote: >> Thank you for filling out a Git bug report! >> Please answer the following questions to help us understand your issue. >> >> What did you do before the bug happened? (Steps to reproduce your issue) >> Pushing to a directory directly. >> >> What did you expect to happen? (Expected behavior) >> Good behavior >> >> What happened instead? (Actual behavior) >> Disk errors. After pushing to a directory (my origin field is C:\Work for >> example) the git repository will be corrupted. >> Moreover causing disk errors not only in the target git bare repository. >> I've loosed some other files. >> Cannot be reproduced exactly. However I have decided to report this problem. >> I've experienced this problem for several years. > > There's nothing that Git should be able to do as a normal operating > system that causes disk errors. If you're seeing those kinds of errors, > the likelihood is that your disk is bad and you need to replace it. > > Do note that if you're storing your data in a directory managed by a > cloud syncing service (e.g., Dropbox or OneDrive), then it is known that > those file systems corrupt Git repositories and you shouldn't use them > with Git. That's due to the way they sync data. > > However, if this is a regular file system (e.g., NTFS), then Git > shouldn't be able to cause disk problems, and if it could, that would be > a serious defect in Windows, so it's almost certainly going to be a > hardware problem. I think you're most likely right that this is some local HW issue, but the report doesn't have enough information to say either way. But generally as we've been discussing at length in various threads related to git's fsync() behavior we can and will corrupt repositories due only to our own (mis)use of FS APIs, i.e. not doing fsyncing and the like correctly, it's been improved a bit recently. But we're still in a state of not doing it correctly, and/or relying on some implicit assumptions. For something like an external disk that may have its power cable yanked I'd give it about even odds that it's HW v.s. git's own FS syncing logic being at fault. We get away with a lot of shenanigans because we're usually on a journaled FS, which e.g. on a FAT32 external volume we won't benefit from. Attila: I have no idea if this even exists on Windows, but aside from other suggestions in this thread I'd suggest enabling whatever Window's equivalent of "sync" mounting is (if it even exists). I.e. to have every single FS operation by synced to the metal. It will make your repository *much much slower*, but it will be safe as far as any logic errors in git vis-a-vis syncing go.
