Doing an "strace" on "git diff" shows that we close() a file descriptor twice (getting EBADFD on the second one) when we end up in ce_compare_data if the index does not match the checked-out stat information. The "index_fd()" function will already have closed the fd for us, so we should not close it again. Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx> --- The way I found this also showed a potential performance problem: if you do a "git reset --hard" (or similar) after you have changes in your tree, it will write the index file with the same timestamp as the checked out files that it re-wrote. That will also then forever afterwards (well, until the next "git update-index --refresh") cause the "uncommon" timestamp case in ce_match_stat(), where we check the index-file timestamp against the timestamp of the stat data, to trigger. Not very good. The "ce_modified_check_fs()" tests can be quite expensive if you have lots of those files because we end up then calling the "ce_compare_data()" function a lot. And suddenly "git diff" doesn't take a tenth of a second any more. We should really try to have some way to re-generate the index automatically when this case triggers, so that we only need to do it _once_ rather than keep doing it forever while the index is "potentially stale". Any ideas? diff --git a/read-cache.c b/read-cache.c index c0b0313..f92cdaa 100644 --- a/read-cache.c +++ b/read-cache.c @@ -61,7 +61,7 @@ static int ce_compare_data(struct cache_ unsigned char sha1[20]; if (!index_fd(sha1, fd, st, 0, NULL)) match = memcmp(sha1, ce->sha1, 20); - close(fd); + /* index_fd() closed the file descriptor already */ } return match; } - : 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