Linus Torvalds <torvalds@xxxxxxxx> writes: > Yes, there should be a fflush() there before the fsync. While I have your attention... The code that follows the committing of packed-refs file by calling rename() to move the lock file to its final name prunes already packed refs, and we should really make sure the effect of rename() survives before starting to remove loose refs from the filesystem. How would one ensure the effect of rename(2) hits the disk platter before proceeding to do something else? We seem to do sync(1) in git-repack.sh for similar reasons, and I wonder if we should do a sync(2) there. I doubt it would be worth it though; the function can return before the actual writing is done. If the write-out of metainfo is ordered enough that if we rename the packed-refs lock file to its final destination and then we unlink loose refs, it might be reasonably safe to assume that rename(2)'s effect has already hit the disk when the effect of unlink(2) does, of the machine crashes in the meantime, as long as none of the later unlink hits the disk before rename does it is Ok. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html