git-commit: fix double close(2) that can close a wrong file descriptor
commit4439751dcbc3ba2fccae70626654f7950a7b298c
authorKristian Høgsberg <krh@redhat.com>
Tue, 15 Jan 2008 20:00:02 +0000 (15 15:00 -0500)
committerJunio C Hamano <gitster@pobox.com>
Wed, 16 Jan 2008 01:33:53 +0000 (15 17:33 -0800)
treeb3ad1d6be4b2b311a14da7685b617ff8e3571bcf
parent1bc7c13af9f936aa80893100120b542338a10bf4
git-commit: fix double close(2) that can close a wrong file descriptor

The codepath to prepare index files for the temporary and next
index file was closing file descriptor it obtained from the
lockfile API by hand, without letting the API know that the fd
should not be doubly closed.

This is not usually a problem (except it may get EBADFD) but if
we opened another fd for an entirely unrelated purpose (say, an
fd used to mmap a packfile) between the time we close the fd to
the index file and the time we commit or rollback the lockfile
(causing it to also try closing the recorded fd), the lockfile
API will close an incorrect file descriptor that is still used
for an entirely unrelated purpose.

There's four close(fd) calls in prepare_index() and they're all
incorrect.  The open fd's are cleaned up in rollback_index_files() and
shouldn't be closed manually.  The patch below gets rid of the extra
close() calls and should fix the problem.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-commit.c