From: Junio C Hamano <gitster@pobox.com>
To: Ronnie Sahlberg <sahlberg@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Remove the close_ref function.
Date: Tue, 08 Apr 2014 14:50:06 -0700 [thread overview]
Message-ID: <xmqqeh173301.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1396991830-20938-2-git-send-email-sahlberg@google.com> (Ronnie Sahlberg's message of "Tue, 8 Apr 2014 14:17:10 -0700")
Ronnie Sahlberg <sahlberg@google.com> writes:
> @@ -2824,8 +2816,7 @@ int write_ref_sha1(struct ref_lock *lock,
> return -1;
> }
> if (write_in_full(lock->lock_fd, sha1_to_hex(sha1), 40) != 40 ||
> - write_in_full(lock->lock_fd, &term, 1) != 1
> - || close_ref(lock) < 0) {
> + write_in_full(lock->lock_fd, &term, 1) != 1) {
In the original code, we try to write the new object name and the
line terminator, and also try to make sure that the file descriptor
is successfully closed here. Only when all of that is done
successfully we go update the reflog and then after that, we commit
the lockfile by renaming.
With the updated code, these two write(2)s may succeed, but we would
not know if the close(2) would succeed, until commit_lock_file() is
called much later in this codepath.
We would end up updating the reflog even when the close(2) of the
ref fails.
To be really paranoid, we should probably be doing an fsync(2)
to make sure that the bytes written hit the disk platter, not just
close(2), and such a change may be a good step in the direction to
make the code more robust; in that light, the patch goes in the
opposite direction "what it does is not robust enough anyway, so
let's loosen it further".
Hmm...
next prev parent reply other threads:[~2014-04-08 21:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-08 21:17 [PATCH] Remove redundant close_ref function Ronnie Sahlberg
2014-04-08 21:17 ` [PATCH] Remove the " Ronnie Sahlberg
2014-04-08 21:50 ` Junio C Hamano [this message]
2014-04-08 22:23 ` Ronnie Sahlberg
2014-04-08 21:32 ` [PATCH] Remove redundant " Junio C Hamano
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=xmqqeh173301.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=sahlberg@google.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.
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.