Re: Git bug report - disk errors on Windows after push

>
>
> 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.