From: Junio C Hamano <gitster@pobox.com>
To: Ephrim Khong <dr.khong@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH] merge-recursive: create new files with O_EXCL
Date: Wed, 10 Mar 2021 15:01:58 -0800 [thread overview]
Message-ID: <xmqqblbqipeh.fsf@gitster.g> (raw)
In-Reply-To: <f6cd9386-8a58-ee52-4c7b-60d9bd14a51d@gmail.com> (Ephrim Khong's message of "Wed, 10 Mar 2021 08:57:43 +0100")
Ephrim Khong <dr.khong@gmail.com> writes:
> When re-writing the content of a file during a merge, the file
> is first unlinked and then re-created. Since it is a new file
> at the time of the open call, O_EXCL should be passed to clarify
> that the file is expected to be new.
>
> Signed-off-by: Ephrim Khong <dr.khong@gmail.com>
> ---
> This is actually a fix for an issue we ran into on an nfs4
> mount. Files created with O_TRUNC instead of O_EXCL sometimes
> had their permissions wrong. However, it appears to be a safe
> thing to change this, especially since other parts of the
> git codebase also prefer the O_EXCL flag.
Interesting.
It seems that this part of the code has always used O_TRUNC since
its inception at 6d297f81 (Status update on merge-recursive in C,
2006-07-08) when two thieves smuggled it into our codebase. Back
then, this was the only use of O_TRUNC|O_WRONLY|O_CREAT combination
in the production codebase (as you observed, O_CREAT|O_EXCL|O_WRONLY
was what all the other codepaths use). But the use of O_TRUNC has
spread over time to other parts of the codebase, perhaps cargo
culted. If you look at hits from
$ git grep -e O_TRUNC -e O_EXCL
you see the combination of CREAT/WRONLY/TRUNC used all over the
place [*], especially in newer parts of the code.
So it becomes very curious why this one location needs to be so
special and you are not patching other uses of O_TRUNC.
I do not think we mind fixing the use of O_TRUNC with "remove and
then create with O_EXCL", but we'd probably want to
* understand why only this place matters, or perhaps other uses of
O_TRUNC needs the same fix to work "correctly" with your NFS
mounts, in which case we'd need all of them addressed in the same
series of patches, and
* understand why your NFS mount is broken and give a better
explanation as to why we need to have a workaround in our code.
before doing so.
Thanks.
[Footnote]
* It is understandable that CREAT/WRONLY/TRUNC are used in
combination, as that is documented as a synonym for creat().
> merge-recursive.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index f736a0f632..f72a376c5b 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -974,7 +974,7 @@ static int update_file_flags(struct merge_options *opt,
> int fd;
> int mode = (contents->mode & 0100 ? 0777 : 0666);
>
> - fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
> + fd = open(path, O_WRONLY | O_EXCL | O_CREAT, mode);
> if (fd < 0) {
> ret = err(opt, _("failed to open '%s': %s"),
> path, strerror(errno));
next prev parent reply other threads:[~2021-03-10 23:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 7:57 [RFC PATCH] merge-recursive: create new files with O_EXCL Ephrim Khong
2021-03-10 23:01 ` Junio C Hamano [this message]
2021-03-11 9:54 ` Ephrim Khong
2021-03-11 17:52 ` Junio C Hamano
2021-03-11 18:01 ` Elijah Newren
2021-03-13 1:08 ` brian m. carlson
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=xmqqblbqipeh.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=dr.khong@gmail.com \
--cc=git@vger.kernel.org \
/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).