From: Shawn Pearce <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 4/5] Log ref updates made by fetch.
Date: Fri, 19 May 2006 04:03:14 -0400 [thread overview]
Message-ID: <20060519080314.GG22257@spearce.org> (raw)
In-Reply-To: <7vodxuih2d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > diff --git a/refs.c b/refs.c
> > index 31cf276..d3ddc82 100644
> > --- a/refs.c
> > +++ b/refs.c
> > @@ -142,6 +142,8 @@ static int do_for_each_ref(const char *b
> > namelen = strlen(de->d_name);
> > if (namelen > 255)
> > continue;
> > + if (namelen>5 && !strcmp(de->d_name+namelen-5,".lock"))
> > + continue;
> > memcpy(path + baselen, de->d_name, namelen+1);
> > if (stat(git_path("%s", path), &st) < 0)
> > continue;
>
> Now this got me worried. Until now I did not realize that we
> are clobbering refnames that ends with ".lock" if another ref
> with the name without ".locK" is updated. Because we do not
> forbid a name that ends with ".lock" to be used as a refname,
> this is an accident waiting to happen.
>
> Not your fault, though. It was like this ever since the initial
> version of refs.c was accepted by Linus.
>
> We could do one of two things: officially forbid any refname
> that ends with ".lock", or fix the lockfile naming convention.
>
> Nobody should be relying on what the actual lockfile-to-be-
> renamed-to-become-the-real-file is called. I suspect we would
> want to fix refs.c::ref_lock_file_name() to use a name that
> would never be used as a refname.
>
> We could make it begin with ".", so the lock file for the master
> ".git/refs/heads/master" would become ".git/refs/heads/.master",
> for example. That way, we cannot clobber a valid unrelated ref
> (".master" is not a valid ref name), and as an added bonus, you
> do not even have to have the above hunk.
Not a bad idea. I found this bug because fetch.c was trying to
work on the bob.lock while it was fetching "heads/bob". Which
didn't make sense to me, so I put this skip thing in...
I'd want to get all of the "lockers" move to using the common
lock code before changing the lock name to ".master" (for example)
but yes that's a good idea.
--
Shawn.
prev parent reply other threads:[~2006-05-19 8:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-19 7:29 [PATCH 4/5] Log ref updates made by fetch Shawn Pearce
2006-05-19 7:56 ` Junio C Hamano
2006-05-19 8:03 ` Shawn Pearce [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060519080314.GG22257@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.