check_and_freshen_file: fix reversed success-check
commit3096b2ecdb91c27cb9e64b692c480deed6c7e77e
authorJeff King <peff@peff.net>
Wed, 8 Jul 2015 20:33:52 +0000 (8 16:33 -0400)
committerJunio C Hamano <gitster@pobox.com>
Wed, 8 Jul 2015 22:58:28 +0000 (8 15:58 -0700)
treebb4a0d16e25322070d0ed5d2524c1ce88e156117
parent33d4221c79c89844bed6b9558cc2bc497251ef70
check_and_freshen_file: fix reversed success-check

When we want to write out a loose object file, we have
always first made sure we don't already have the object
somewhere. Since 33d4221 (write_sha1_file: freshen existing
objects, 2014-10-15), we also update the timestamp on the
file, so that a simultaneous prune knows somebody is
likely to reference it soon.

If our utime() call fails, we treat this the same as not
having the object in the first place; the safe thing to do
is write out another copy. However, the loose-object check
accidentally inverts the utime() check; it returns failure
_only_ when the utime() call actually succeeded. Thus it was
failing to protect us there, and in the normal case where
utime() succeeds, it caused us to pointlessly write out and
link the object.

This passed our freshening tests, because writing out the
new object is certainly _one_ way of updating its utime. So
the normal case was inefficient, but not wrong.

While we're here, let's also drop a comment in front of the
check_and_freshen functions, making a note of their return
type (since it is not our usual "0 for success, -1 for
error").

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_file.c