git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Remove the close_ref function.

From
Ronnie Sahlberg <sahlberg@google.com>
Date
Apr 8, 2014, 22:23 UTC
Message-ID
<CAL=YDWk3CkLG5P18GFhUKKQ9bEqOeJayNxKCiTMRtg-d4K_smw@mail.gmail.com>
In-Reply-To
<xmqqeh173301.fsf@gitster.dls.corp.google.com>
On Tue, Apr 8, 2014 at 2:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 32 quoted lines
> 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...
>

Good point. Thanks. Please consider this patch abandoned.

Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 5 in “Remove redundant close_ref function”
  1. Remove redundant close_ref functionRonnie Sahlberg, Apr 8, 2014
  2. Remove the close_ref function.Ronnie Sahlberg, Apr 8, 2014
  3. Junio C HamanoApr 8, 2014
  4. Ronnie SahlbergApr 8, 2014
  5. Junio C HamanoApr 8, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.