Re: [HELP] Corrupted repository

Junio C Hamano [off-list ref] writes:

Ramkumar Ramachandra [off-list ref] writes:

quoted

Junio C Hamano wrote:

quoted

quoted

  $ ~/src/git
  error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
  error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
  fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt

So fsync() and close() thought that the filesystem stored this loose
object safely, but it turns out that the data is not on disk.

Where should I start digging if I want to fix this?  Actually you just
need to tell me how to build reduced-case corruptions to test: I can
trace and figure out the rest.

That is a trip in the kernel source, isn't it?  I cannot be your
guide there.

Not necessarily. AFAICT, Git won't fsync object files by default, but
does for pack files (to make sure the pack is written before unlinking
the object files being packed):

       core.fsyncobjectfiles
           This boolean will enable fsync() when writing object files.

           This is a total waste of time and effort on a filesystem that
           orders data writes properly, but can be useful for
           filesystems that do not use journalling (traditional UNIX
           filesystems) or that only journal metadata and not file
           contents (OS X’s HFS+, or Linux ext3 with "data=writeback").


-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/