From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
"Derrick Stolee" <stolee@gmail.com>,
"Renato Botelho" <garga@FreeBSD.org>,
"Todd Zullinger" <tmz@pobox.com>,
"Đoàn Trần Công Danh" <congdanhqx@gmail.com>
Subject: Re: [PATCH] gc: use temporary file for editing crontab
Date: Tue, 23 Aug 2022 11:12:21 +0200 (CEST) [thread overview]
Message-ID: <6428252p-ssrn-7qs7-9p26-5so10r96s3os@tzk.qr> (raw)
In-Reply-To: <20220823010120.25388-1-sandals@crustytoothpaste.net>
Hi brian,
On Tue, 23 Aug 2022, brian m. carlson wrote:
> While cron is specified by POSIX, there are a wide variety of
> implementations in use. On FreeBSD, the cron implementation requires a
> file name argument: if the user wants to edit standard input, they must
> specify "-". However, this notation is not specified by POSIX, allowing
> the possibility that making such a change may break other, less common
> implementations.
>
> Since POSIX tells us that cron must accept a file name argument, let's
> solve this problem by specifying a temporary file instead. This will
> ensure that we work with the vast majority of implementations.
>
> Reported-by: Renato Botelho <garga@FreeBSD.org>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Beautiful commit message. Thank you!
> diff --git a/builtin/gc.c b/builtin/gc.c
> index eeff2b760e..168dbdb5d9 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -2065,6 +2065,7 @@ static int crontab_update_schedule(int run_maintenance, int fd)
> struct child_process crontab_edit = CHILD_PROCESS_INIT;
> FILE *cron_list, *cron_in;
> struct strbuf line = STRBUF_INIT;
> + struct tempfile *tmpedit;
>
> get_schedule_cmd(&cmd, NULL);
> strvec_split(&crontab_list.args, cmd);
> @@ -2079,6 +2080,15 @@ static int crontab_update_schedule(int run_maintenance, int fd)
> /* Ignore exit code, as an empty crontab will return error. */
> finish_command(&crontab_list);
>
> + tmpedit = mks_tempfile_t(".git_cron_edit_tmpXXXXXX");
> + if (!tmpedit)
> + return error(_("failed to create crontab temporary file"));
It might make sense to use the same `goto out;` pattern here, to make it
easier to reason about the early exit even six years from now.
We do not even have to guard the `close_tempfile_gently()` behind an `if
(tempfile)` conditional because that function handles `NULL` parameters
gently.
> + cron_in = fdopen_tempfile(tmpedit, "w");
> + if (!cron_in) {
> + result = error(_("failed to open temporary file"));
> + goto out;
> + }
> +
> /*
> * Read from the .lock file, filtering out the old
> * schedule while appending the new schedule.
> @@ -2086,19 +2096,6 @@ static int crontab_update_schedule(int run_maintenance, int fd)
> cron_list = fdopen(fd, "r");
> rewind(cron_list);
>
> - strvec_split(&crontab_edit.args, cmd);
> - crontab_edit.in = -1;
> - crontab_edit.git_cmd = 0;
> -
> - if (start_command(&crontab_edit))
> - return error(_("failed to run 'crontab'; your system might not support 'cron'"));
> -
> - cron_in = fdopen(crontab_edit.in, "w");
> - if (!cron_in) {
> - result = error(_("failed to open stdin of 'crontab'"));
> - goto done_editing;
> - }
> -
> while (!strbuf_getline_lf(&line, cron_list)) {
> if (!in_old_region && !strcmp(line.buf, BEGIN_LINE))
> in_old_region = 1;
> @@ -2132,14 +2129,22 @@ static int crontab_update_schedule(int run_maintenance, int fd)
> }
>
> fflush(cron_in);
> - fclose(cron_in);
> - close(crontab_edit.in);
This worries me a bit. I could imagine that keeping the file open and then
expecting a spawned process to read its stdin from that file won't work on
Windows.
In any case, I would consider it the correct thing to do to close
the temp file here. In other words, I would like to move the
`close_tempfile_gently()` call to this location.
>
> -done_editing:
> + strvec_split(&crontab_edit.args, cmd);
> + strvec_push(&crontab_edit.args, get_tempfile_path(tmpedit));
> + crontab_edit.git_cmd = 0;
> +
> + if (start_command(&crontab_edit)) {
> + result = error(_("failed to run 'crontab'; your system might not support 'cron'"));
> + goto out;
> + }
> +
> if (finish_command(&crontab_edit))
> result = error(_("'crontab' died"));
> else
> fclose(cron_list);
> +out:
> + close_tempfile_gently(tmpedit);
Here, I would like to call `delete_tempfile(&tmpedit);` instead. That way,
the memory is released correctly, the temporary file is deleted, and
everything is neatly cleaned up.
The way I read the code, `delete_tempfile(&tmpedit)` would return early if
`tmpedit == NULL`, and otherwise clean everything up and release the
memory, so there is no need to guard this call behind an `if (tmpedit)`
conditional.
Side note: I do notice that `delete_tempfile(&tmpedit)` seems to _not_
release memory when `tmpedit` is non-NULL when `tmpedit->active == 0`.
I consider this a bug in the `delete_tempfile()` code (in its `if
(!is_tempfile_active(tempfile))` clause, it should call
`deactivate_tempfile()` for non-NULL `tempfile`s and set `*tempfile_p =
NULL;`), but it is outside the scope of your patch to address that.
What do you think about my suggestions?
Thanks,
Dscho
> return result;
> }
>
>
next prev parent reply other threads:[~2022-08-23 10:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-12 13:51 git maintenance broken on FreeBSD Renato Botelho
2022-08-12 14:44 ` Đoàn Trần Công Danh
2022-08-13 3:42 ` Todd Zullinger
2022-08-13 5:02 ` Junio C Hamano
2022-08-13 15:37 ` Đoàn Trần Công Danh
2022-08-13 17:26 ` Junio C Hamano
2022-08-13 17:35 ` brian m. carlson
2022-08-15 13:22 ` Derrick Stolee
2022-08-15 16:09 ` Junio C Hamano
2022-08-23 1:01 ` [PATCH] gc: use temporary file for editing crontab brian m. carlson
2022-08-23 9:12 ` Johannes Schindelin [this message]
2022-08-23 17:06 ` Derrick Stolee
2022-08-23 21:15 ` brian m. carlson
2022-08-24 16:06 ` Junio C Hamano
2022-08-28 21:41 ` [PATCH v2] " brian m. carlson
2022-08-29 6:46 ` Junio C Hamano
2022-08-29 10:52 ` Renato Botelho
2022-08-30 13:27 ` Derrick Stolee
2022-08-30 20:40 ` [PATCH] test-crontab: minor memory and error handling fixes 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=6428252p-ssrn-7qs7-9p26-5so10r96s3os@tzk.qr \
--to=johannes.schindelin@gmx.de \
--cc=congdanhqx@gmail.com \
--cc=garga@FreeBSD.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@gmail.com \
--cc=tmz@pobox.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 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).