git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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;
>  }
>
>

  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).