]> git.ipfire.org Git - thirdparty/git.git/commit - entry.c
Do not expect unlink(2) to fail on a directory.
authorJunio C Hamano <gitster@pobox.com>
Wed, 18 Jul 2007 05:58:28 +0000 (22:58 -0700)
committerJunio C Hamano <gitster@pobox.com>
Wed, 18 Jul 2007 07:53:09 +0000 (00:53 -0700)
commitfa2e71c9e794c43634670b62d1b4bf58d1ae7e60
tree76c39fedea03cac74bbfd31bb373f40cd3fe3e3c
parentffb293b63d13b3b06b454a5f9f0ff6802ef15f0d
Do not expect unlink(2) to fail on a directory.

When "git checkout-index" checks out path A/B/C, it makes sure A
and A/B are truly directories; if there is a regular file or
symlink at A, we prefer to remove it.

We used to do this by catching an error return from mkdir(2),
and on EEXIST did unlink(2), and when it succeeded, tried
another mkdir(2).

Thomas Glanzmann found out the above does not work on Solaris
for a root user, as unlink(2) was so old fashioned there that it
allowed to unlink a directory.

As pointed out, this still doesn't guarantee that git won't call
"unlink()" on a directory (race conditions etc), but that's
fundamentally true (there is no "funlink()" like there is
"fstat()"), and besides, that is in no way git-specific (ie it's
true of any application that gets run as root).

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
entry.c