From: Junio C Hamano <gitster@pobox.com>
To: "Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Han-Wen Nienhuys <hanwenn@gmail.com>,
Han-Wen Nienhuys <hanwen@google.com>
Subject: Re: [PATCH 3/3] reftable: support preset file mode for writing
Date: Thu, 23 Dec 2021 20:46:28 -0800 [thread overview]
Message-ID: <xmqqsfui4nkr.fsf@gitster.g> (raw)
In-Reply-To: c01b1c335a33e5f44289c520a1634d071d882223.1640287790.git.gitgitgadget@gmail.com
"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Han-Wen Nienhuys <hanwen@google.com>
>
> Create files with mode 0666, so umask works as intended. Provides an override,
> which is useful to support shared repos (test t1301-shared-repo.sh).
> + /* Default mode for creating files. If unset, use 0666 (+umask) */
> + unsigned int default_permissions;
> +
Presumably this is primed by a call to get_shared_repository(),
possibly followed by calc_shared_perm(), but having it in the
interface is a good idea, as it allows us to avoid making these
git-core specific calls from reftable/ library proper?
> diff --git a/reftable/stack.c b/reftable/stack.c
> index df5021ebf08..56bf5f2d84a 100644
> --- a/reftable/stack.c
> +++ b/reftable/stack.c
> @@ -469,7 +469,7 @@ static int reftable_stack_init_addition(struct reftable_addition *add,
> strbuf_addstr(&add->lock_file_name, ".lock");
>
> add->lock_file_fd = open(add->lock_file_name.buf,
> - O_EXCL | O_CREAT | O_WRONLY, 0644);
> + O_EXCL | O_CREAT | O_WRONLY, 0666);
This change makes sense.
> if (add->lock_file_fd < 0) {
> if (errno == EEXIST) {
> err = REFTABLE_LOCK_ERROR;
> @@ -478,6 +478,13 @@ static int reftable_stack_init_addition(struct reftable_addition *add,
> }
> goto done;
> }
> + if (st->config.default_permissions) {
> + if (chmod(add->lock_file_name.buf, st->config.default_permissions) < 0) {
> + err = REFTABLE_IO_ERROR;
> + goto done;
This part does not exactly make sense, though.
If this were a library code meant to link with ONLY with Git, I
would have recommended to make a adjust_shared_perm() call from
here, without having to have "unsigned int default_permissions" to
reftable_write_options structure.
I wonder if it is a better design to make the new member in the
structure a pointer to a generic and opaque helper function that is
called from here, i.e.
if (st->config.adjust_perm &&
st->config.adjust_perm(add->lock_file_name.buf) < 0) {
err = REFTABLE_IO_ERROR;
goto done;
}
so that when linking with and calling from git, we can just stuff
the pointer to adjust_shared_perm function to the member?
> + }
> + }
> +
next prev parent reply other threads:[~2021-12-24 4:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-23 19:29 [PATCH 0/3] preliminary fixes for reftable support Han-Wen Nienhuys via GitGitGadget
2021-12-23 19:29 ` [PATCH 1/3] reftable: fix typo in header Han-Wen Nienhuys via GitGitGadget
2021-12-23 19:29 ` [PATCH 2/3] reftable: signal overflow Han-Wen Nienhuys via GitGitGadget
2021-12-23 19:29 ` [PATCH 3/3] reftable: support preset file mode for writing Han-Wen Nienhuys via GitGitGadget
2021-12-24 4:46 ` Junio C Hamano [this message]
2022-01-10 19:01 ` Han-Wen Nienhuys
2022-01-10 19:14 ` Junio C Hamano
2021-12-23 20:27 ` [PATCH 0/3] preliminary fixes for reftable support Junio C Hamano
2021-12-24 2:15 ` 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=xmqqsfui4nkr.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=hanwen@google.com \
--cc=hanwenn@gmail.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.