Hi, We are developing a tool to find bugs, and it flagged a potential problem in git-add. We are checking git 1.7.9.4, and this problem still exists in the latest release, git 1.7.10. At the end of cmd_add() in builtin/add.c, there is a call to write_cache(), followed by commit_locked_index(). 474: if (write_cache(newfd, active_cache, active_nr) || 475: commit_locked_index(&lock_file)) In write_cache(), the program wrote to the locked index file, and in commit_locked_index(), it did an atomic rename to rename the locked index file to the real index file. However, the locked index file is not synced to the disk before being renamed to the real index file. This may cause data loss, which has been pointed out in this post: http://stackoverflow.com/questions/7433057/is-rename-without-fsync-safe If a crash happens after the rename(), the data may have not been completely flushed into the index file, so the user may face an empty or corrupted index file. Although the user may just recreate the index file, he would need to add the files to be committed again, which may be inconvenient and disturbing. To fix this problem, we may just do a fsync() before renaming the file. We can add this to close_lock_file() in lockfile.c: 223: int close_lock_file(struct lock_file *lk) 224: { 225: int fd = lk->fd; 226: lk->fd = -1; // we may add // fsync(fd); // here 227: return close(fd); 228:} Is this a real problem? Any clarification or confirmation is appreciated. Thank you. -- Cheers, Gang -- 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