On Wed, 4 Oct 2006, Junio C Hamano wrote: > > 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. sync() is supposed to wait until the data is on the disk, anything else is likely to be a bad implementation (even if POSIX may not _guarantee_ it). Also, most filesystems (for various reasons, not the least of which is "speed of fsck") will journal metadata, but not file contents. Which means that if a crash happens and one of the loose refs has already been removed, then (thanks to journaling) that means that on most filesystems the rename would already have been guaranteed to hit the disk - even regardless of any sync(). So in practice, it's much more important to guarantee the file contents (the fsync) part, because the OS already tends to guarantee metadata ordering. Linus - 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