git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Jeff King <peff@peff.net>, Derrick Stolee <dstolee@microsoft.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	"gitster@pobox.com" <gitster@pobox.com>
Subject: Re: [PATCH 1/1] commit-graph: fix UX issue when .lock file exists
Date: Wed, 9 May 2018 10:53:56 -0400	[thread overview]
Message-ID: <926ef4a5-83c1-3d5f-6dfc-0b74fc7090bd@gmail.com> (raw)
In-Reply-To: <20180509144221.GA14714@sigill.intra.peff.net>

On 5/9/2018 10:42 AM, Jeff King wrote:
> On Wed, May 09, 2018 at 02:15:38PM +0000, Derrick Stolee wrote:
>
>> The commit-graph file lives in the .git/objects/info directory.
>> Previously, a failure to acquire the commit-graph.lock file was
>> assumed to be due to the lack of the info directory, so a mkdir()
>> was called. This gave incorrect messaging if instead the lockfile
>> was open by another process:
>>
>>    "fatal: cannot mkdir .git/objects/info: File exists"
>>
>> Rearrange the expectations of this directory existing to avoid
>> this error, and instead show the typical message when a lockfile
>> already exists.
> Sounds like a reasonable bug fix.
>
> Your cover letter is way longer than this description. Should some of
> that background perhaps go in the commit message?

I did want a place to include the full die() message in the new 
behavior, but that seemed like overkill for the commit message.

> (I would go so far as to say that sending a cover letter for a single
> patch is an anti-pattern, because the commit message should be able to
> stand on its own).
>
>> @@ -754,23 +755,14 @@ void write_commit_graph(const char *obj_dir,
>>   	compute_generation_numbers(&commits);
>>   
>>   	graph_name = get_commit_graph_filename(obj_dir);
>> -	fd = hold_lock_file_for_update(&lk, graph_name, 0);
>>   
>> -	if (fd < 0) {
>> -		struct strbuf folder = STRBUF_INIT;
>> -		strbuf_addstr(&folder, graph_name);
>> -		strbuf_setlen(&folder, strrchr(folder.buf, '/') - folder.buf);
>> -
>> -		if (mkdir(folder.buf, 0777) < 0)
>> -			die_errno(_("cannot mkdir %s"), folder.buf);
>> -		strbuf_release(&folder);
>> -
>> -		fd = hold_lock_file_for_update(&lk, graph_name, LOCK_DIE_ON_ERROR);
>> -
>> -		if (fd < 0)
>> -			die_errno("unable to create '%s'", graph_name);
>> -	}
>> +	strbuf_addstr(&folder, graph_name);
>> +	strbuf_setlen(&folder, strrchr(folder.buf, '/') - folder.buf);
>> +	if (!file_exists(folder.buf) && mkdir(folder.buf, 0777) < 0)
>> +		die_errno(_("cannot mkdir %s"), folder.buf);
>> +	strbuf_release(&folder);
> The result is racy if somebody else is trying to create the directory at
> the same time. For that you'd want to notice EEXIST coming from mkdir
> and consider that a success.
>
> I think you probably ought to be calling adjust_shared_perm() on the
> result, too, in case core.sharedrepository is configured.
>
> If you use safe_create_leading_directories(), it should handle both.
> Something like:
>
>    if (safe_create_leading_directories(graph_name))
> 	die_errno(_("unable to create leading directories of %s"),
> 		  graph_name));
>
> I think I'm holding it right; that function is a little short on
> documentation, but it's the standard way to do this in Git's codebase,
> and you can find lots of example callers.

Thanks for this method. I was unfamiliar with it. Saves the effort of 
creating the strbuf, too.

Thanks,
-Stolee

  reply	other threads:[~2018-05-09 14:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 14:15 [PATCH 0/1] Fix UX issue with commit-graph.lock Derrick Stolee
2018-05-09 14:15 ` [PATCH 1/1] commit-graph: fix UX issue when .lock file exists Derrick Stolee
2018-05-09 14:42   ` Jeff King
2018-05-09 14:53     ` Derrick Stolee [this message]
2018-05-10  4:53       ` Jeff King
2018-05-09 16:02 ` [PATCH 0/1] Fix UX issue with commit-graph.lock Duy Nguyen
2018-05-10  7:00 ` Junio C Hamano
2018-05-10 12:52   ` Derrick Stolee
2018-05-11  1:28     ` Junio C Hamano
2018-05-10 17:42 ` [PATCH v2] commit-graph: fix UX issue when .lock file exists Derrick Stolee
2018-05-11  8:59   ` Jeff King

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=926ef4a5-83c1-3d5f-6dfc-0b74fc7090bd@gmail.com \
    --to=stolee@gmail.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).