From: Jeff King <peff@peff.net>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: "Junio C Hamano" <gitster@pobox.com>,
git@vger.kernel.org, "Torsten Bögershausen" <tboegi@web.de>,
"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH v2 17/25] commit_lock_file(): make committing an unlocked lockfile a NOP
Date: Mon, 7 Apr 2014 15:31:31 -0400 [thread overview]
Message-ID: <20140407193131.GC19342@sigill.intra.peff.net> (raw)
In-Reply-To: <1396827247-28465-18-git-send-email-mhagger@alum.mit.edu>
On Mon, Apr 07, 2014 at 01:33:59AM +0200, Michael Haggerty wrote:
> It was previously a bug to call commit_lock_file() with a lock_file
> object that was not active (an illegal access would happen within the
> function). It was presumably never done, but this would be an easy
> programming error to overlook. So guard the file-renaming code with
> an if statement to change committing an unlocked file into a NOP.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> Alternatively, we could make it a fatal error (e.g., an assert() or
> if...die()) to call commit_lock_file() on an unlocked file, or omit a
> warning in this case. But since it is so hard to test code related to
> locking failures, I have the feeling that such an error is most likely
> to occur in some error-handling path, maybe when some other lockfile
> acquisition has failed, and it would be better to let the code
> continue its attempted cleanup instead of dying. But it would be easy
> to persuade me to change my opinion.
Yeah, I would have expected a die("BUG") here.
I think it is worth making it a fatal mistake and catching it. Rolling
back an uninitialized lockfile is probably OK; we are canceling an
operation that never started. But committing a lockfile that we didn't
actually fill out could be a sign of a serious error, and we may be
propagating a bogus success code. E.g., imagine that receive-pack claims
to have written your ref, but actually commit_lock_file was a silent
NOP. I'd much rather have it die loudly so we can track down the case.
-Peff
next prev parent reply other threads:[~2014-04-07 19:31 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-06 23:33 [PATCH v2 00/25] Lockfile correctness and refactoring Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 01/25] api-lockfile: expand the documentation Michael Haggerty
2014-04-07 18:46 ` Jeff King
2014-04-06 23:33 ` [PATCH v2 02/25] unable_to_lock_die(): rename function from unable_to_lock_index_die() Michael Haggerty
2014-04-07 18:47 ` Jeff King
2014-04-08 14:04 ` Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 03/25] rollback_lock_file(): do not clear filename redundantly Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 04/25] rollback_lock_file(): set fd to -1 Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 05/25] lockfile: unlock file if lockfile permissions cannot be adjusted Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 06/25] hold_lock_file_for_append(): release lock on errors Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 07/25] lock_file(): always add lock_file object to lock_file_list Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 08/25] struct lock_file: replace on_list field with flags field Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 09/25] lockfile.c: document the various states of lock_file objects Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 10/25] lockfile: define a constant LOCK_SUFFIX_LEN Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 11/25] delete_ref_loose(): don't muck around in the lock_file's filename Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 12/25] prepare_index(): declare return value to be (const char *) Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 13/25] write_packed_entry_fn(): convert cb_data into a (const int *) Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 14/25] lock_file(): exit early if lockfile cannot be opened Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 15/25] remove_lock_file(): call rollback_lock_file() Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 16/25] commit_lock_file(): inline temporary variable Michael Haggerty
2014-04-06 23:33 ` [PATCH v2 17/25] commit_lock_file(): make committing an unlocked lockfile a NOP Michael Haggerty
2014-04-07 19:31 ` Jeff King [this message]
2014-04-14 8:21 ` Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 18/25] lockfile: avoid transitory invalid states Michael Haggerty
2014-04-07 6:16 ` Johannes Sixt
2014-04-07 11:13 ` Michael Haggerty
2014-04-07 12:12 ` Johannes Sixt
2014-04-07 13:12 ` Michael Haggerty
2014-04-07 19:38 ` Jeff King
2014-04-06 23:34 ` [PATCH v2 19/25] try_merge_strategy(): remove redundant lock_file allocation Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 20/25] try_merge_strategy(): use a statically-allocated lock_file object Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 21/25] commit_lock_file(): use a strbuf to manage temporary space Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 22/25] Change lock_file::filename into a strbuf Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 23/25] resolve_symlink(): use a strbuf for internal scratch space Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 24/25] resolve_symlink(): take a strbuf parameter Michael Haggerty
2014-04-06 23:34 ` [PATCH v2 25/25] trim_last_path_elm(): replace last_path_elm() Michael Haggerty
2014-04-07 19:40 ` [PATCH v2 00/25] Lockfile correctness and refactoring 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140407193131.GC19342@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
--cc=sunshine@sunshineco.com \
--cc=tboegi@web.de \
/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 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 NNTP newsgroup(s).