Junio C Hamano <gits...@pobox.com> writes:

> Ramkumar Ramachandra <artag...@gmail.com> writes:
>> Junio C Hamano wrote:
>>>>   $ ~/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):

           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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to