From: Jeff King <peff@peff.net>
To: Johannes Sixt <j6t@kdbg.org>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"René Scharfe" <l.s.r@web.de>,
"X H" <music_is_live_lg@hotmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: [PATCH] check_and_freshen_file: fix reversed success-check
Date: Wed, 8 Jul 2015 14:33:31 -0400 [thread overview]
Message-ID: <20150708183331.GA16138@peff.net> (raw)
In-Reply-To: <20150708180539.GA12353@peff.net>
On Wed, Jul 08, 2015 at 02:05:39PM -0400, Jeff King wrote:
> The code path should be unpack-objects.c:write_object, which calls
> sha1_file.cwrite_sha1_file, which then checks has_sha1_file(). These
> days it uses the freshen_* functions instead of the latter, which does a
> similar check. But it does report failure if we cannot call utime() on
> the file, preferring to write it out instead (this is the safer choice
> from a preventing-prune-corruption perspective).
>
> So it's possible that the sequence is:
>
> - unpack-objects tries to write object 1234abcd...
>
> - write_sha1_file calls freshen_loose_object
>
> - we call access("12/34abcd...", F_OK) and see that it does indeed
> exist
>
> - we call utime("12/34abcd...") which fails (presumably due to EPERM);
> we return failure and assume we must write out the object
...or maybe in the utime() step there is actually a bug, and we report
failure for no good reason. Ugh.
-- >8 --
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
_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'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;
}
--
2.5.0.rc1.340.ge59e3eb
next prev parent reply other threads:[~2015-07-08 18:33 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 ` Jeff King [this message]
2015-07-08 19:24 ` [PATCH] check_and_freshen_file: fix reversed success-check Junio C Hamano
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=20150708183331.GA16138@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=l.s.r@web.de \
--cc=music_is_live_lg@hotmail.com \
/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).