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.

“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)

Filesystems don't try to order writes to different files. So you get HEAD pointing to a truncated commit, or a commit pointing to a truncated blob.

The same happens if you have a power loss or kernel crash on Linux (as a kernel developer, it happened to me several times when testing freshly-committed code).

Does git actually attempt to write all objects atomically?

Good to know, seems like a design flaw in git then, unless its using fsync correctly.