Skip to content
Browse files

fsync loose objects before moving into place

When we write a loose object to disk, we simply close the
file object before moving it into place. If the machine
crashes shortly after our write, the contents may not have
been committed to disk (depending your filesystem, usually
the metadata is, and you end up with a corrupt, zero-length
loose object file).

This is especially bad because we report that the object is
successfully written, which means we may have updated refs
to point to it. A corrupt object at that point means not
only does the operation fail, but the repository is left in
a corrupted and unusable state.

We can fix this by calling fsync on the object file before
linking it into place. Between this and the previous commit,
our object writing should now behave exactly like git's
internal routines.
  • Loading branch information...
1 parent 9df3589 commit 13d5737ee6de729ed85d951cccaa3127cd22dcde @peff peff committed with rtomayko Feb 21, 2013
Showing with 1 addition and 0 deletions.
  1. +1 −0 lib/grit/git-ruby/internal/loose.rb
1 lib/grit/git-ruby/internal/loose.rb
@@ -66,6 +66,7 @@ def get_raw_object(buf)
def safe_write(path, content)"tmp_obj_", File.dirname(path), :opt => "wb") do |f|
f.write content
+ f.fsync
begin, path)

0 comments on commit 13d5737

Please sign in to comment.
Something went wrong with that request. Please try again.