From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Johannes Sixt" <j6t@kdbg.org>, "René Scharfe" <l.s.r@web.de>,
"X H" <music_is_live_lg@hotmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] check_and_freshen_file: fix reversed success-check
Date: Wed, 08 Jul 2015 12:24:41 -0700 [thread overview]
Message-ID: <xmqqegkixxja.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150708183331.GA16138@peff.net> (Jeff King's message of "Wed, 8 Jul 2015 14:33:31 -0400")
Jeff King <peff@peff.net> writes:
> Subject: 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 inverst the utime() check; it returns failure
s/inverst/invert/?
> _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 of a successful utime() was inefficient, but
> not wrong.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> The worst part of this is that I had the _same_ bug in the pack code
> path when I initially posted what became 33d4221. René noticed during
> review, and my fix was to invert the return value from freshen_file to
> match the other functions. But of course doing that without fixing the
> other caller meant I introduced the same bug there.
I think each of the functions in the check_and_freshen_* callchain
can at least have a comment in front of it, saying what the returned
value means, to unconfuse readers. "Return 1 when the thing exists
and no further action is necessary; return 0 when the thing does not
exist or not in a good state and should be overwritten (if the
caller has something to overwrite it with, that is)" or something?
Their returning "1" instead of "-1" could be taken as a hint that
says "this non-zero return does not signal a _failure_", but it is a
rather weak hint.
>
> I'll be curious if this fixes the problem the OP is seeing. If not, then
> we can dig deeper into the weird EPERM problems around this particular
> object database.
>
> sha1_file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 77cd81d..721eadc 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -454,7 +454,7 @@ static int check_and_freshen_file(const char *fn, int freshen)
> {
> if (access(fn, F_OK))
> return 0;
> - if (freshen && freshen_file(fn))
> + if (freshen && !freshen_file(fn))
> return 0;
> return 1;
> }
next prev parent reply other threads:[~2015-07-08 19:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-07 13:45 Git force push fails after a rejected push (unpack failed)? X H
2015-07-07 14:13 ` Jeff King
[not found] ` <DUB120-W36B78FEE6DC80BDCB05D7FF6920@phx.gbl>
2015-07-07 19:49 ` Jeff King
2015-07-07 23:05 ` Eric Sunshine
2015-07-08 17:41 ` Johannes Sixt
2015-07-08 18:05 ` Jeff King
2015-07-08 18:33 ` [PATCH] check_and_freshen_file: fix reversed success-check Jeff King
2015-07-08 19:24 ` Junio C Hamano [this message]
2015-07-08 20:33 ` [PATCH v2] " Jeff King
2015-07-08 21:03 ` [PATCH] " Johannes Sixt
2015-07-09 20:51 ` Johannes Sixt
2015-07-09 22:48 ` Jeff King
2015-07-11 22:21 ` X H
2015-07-13 3:52 ` Jeff King
2015-07-13 19:58 ` X H
2015-07-08 20:28 ` Git force push fails after a rejected push (unpack failed)? X H
2015-07-08 20:56 ` Johannes Sixt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqegkixxja.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=l.s.r@web.de \
--cc=music_is_live_lg@hotmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).