git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Marc Strapetz via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Marc Strapetz <marc.strapetz@syntevo.com>
Subject: Re: [PATCH v3 1/4] test-lib: introduce API for verifying file mtime
Date: Thu, 06 Jan 2022 15:55:08 -0800	[thread overview]
Message-ID: <xmqqmtk8a083.fsf@gitster.g> (raw)
In-Reply-To: <e6301e9d770bc7b6a2a3eeddcaf4e0123a0b23ab.1641508499.git.gitgitgadget@gmail.com> (Marc Strapetz via GitGitGadget's message of "Thu, 06 Jan 2022 22:34:55 +0000")

"Marc Strapetz via GitGitGadget" <gitgitgadget@gmail.com> writes:

> +# Set a fixed "magic" mtime to the given file,
> +# with an optional increment specified as second argument.
> +# Use in combination with test_is_magic_mtime.
> +test_set_magic_mtime () {
> +	# We are using 1234567890 because it's a common timestamp used in
> +	# various tests. It represents date 2009-02-13 which should be safe
> +	# to use as long as the filetime clock is reasonably accurate.

In the original context of "setting an ancient time, and detect
filesystem modification by noticing that the timestamp has or has
not changed", such an ancient timestamp "should be safe to use", but
if you expose it to more general audience, the context of their use
must be in line with your intended use to be safe.

	# Set mtime to mid February 2009, before we run an operation
	# that may or may not touch the file.  If the file was
	# touched, its timestamp will not accidentally have such an
	# old timestamp, as long as your filesystem clock is
	# reasonably correct.

perhaps?

> +	local inc=${2:-0} &&
> +	local mtime=$((1234567890 + $inc)) &&
> +	test-tool chmtime =$mtime $1 &&
> +	test_is_magic_mtime $1 $inc
> +}

Also as a helper function in the library that is (hopefully) useful
to many other callers, make sure you got your quoting correct.

There is no rule that you must use filenames without SP in it in
your tests, for example, so make sure "$1" above are quoted.  The
same applies to the next function.

> +# Test whether the given file has the "magic" mtime set,
> +# with an optional increment specified as second argument.
> +# Use in combination with test_set_magic_mtime.
> +test_is_magic_mtime () {
> +	local inc=${2:-0} &&
> +	local mtime=$((1234567890 + $inc)) &&
> +	echo $mtime >.git/test-mtime-expect &&
> +	test-tool chmtime --get $1 >.git/test-mtime-actual &&
> +	test_cmp .git/test-mtime-expect .git/test-mtime-actual
> +	local ret=$?
> +	rm .git/test-mtime-expect
> +	rm .git/test-mtime-actual

Use "rm -f" here?  Otherwise, if the main test failed somewhere
before it runs test_cmp, we'd see an error from an attempt to remove
a file that does not exist.

> +	return $ret
> +}

Other than that, quite nicely done (both these two functions and its
users).

Thanks.

  reply	other threads:[~2022-01-06 23:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-22 13:56 [PATCH] update-index: refresh should rewrite index in case of racy timestamps Marc Strapetz via GitGitGadget
2021-12-22 23:52 ` Junio C Hamano
2021-12-23 18:24   ` Marc Strapetz
2022-01-05 13:15 ` [PATCH v2 0/2] " Marc Strapetz via GitGitGadget
2022-01-05 13:15   ` [PATCH v2 1/2] t7508: add tests capturing racy timestamp handling Marc Strapetz via GitGitGadget
2022-01-05 20:59     ` Junio C Hamano
2022-01-06 10:21       ` Marc Strapetz
2022-01-05 13:15   ` [PATCH v2 2/2] update-index: refresh should rewrite index in case of racy timestamps Marc Strapetz via GitGitGadget
2022-01-05 21:03     ` Junio C Hamano
2022-01-06 22:34   ` [PATCH v3 0/4] " Marc Strapetz via GitGitGadget
2022-01-06 22:34     ` [PATCH v3 1/4] test-lib: introduce API for verifying file mtime Marc Strapetz via GitGitGadget
2022-01-06 23:55       ` Junio C Hamano [this message]
2022-01-06 22:34     ` [PATCH v3 2/4] t7508: fix bogus mtime verification Marc Strapetz via GitGitGadget
2022-01-06 22:34     ` [PATCH v3 3/4] t7508: add tests capturing racy timestamp handling Marc Strapetz via GitGitGadget
2022-01-06 22:34     ` [PATCH v3 4/4] update-index: refresh should rewrite index in case of racy timestamps Marc Strapetz via GitGitGadget
2022-01-07 11:17     ` [PATCH v4 0/4] " Marc Strapetz via GitGitGadget
2022-01-07 11:17       ` [PATCH v4 1/4] test-lib: introduce API for verifying file mtime Marc Strapetz via GitGitGadget
2022-01-07 11:17       ` [PATCH v4 2/4] t7508: fix bogus mtime verification Marc Strapetz via GitGitGadget
2022-01-07 11:17       ` [PATCH v4 3/4] t7508: add tests capturing racy timestamp handling Marc Strapetz via GitGitGadget
2022-01-07 11:17       ` [PATCH v4 4/4] update-index: refresh should rewrite index in case of racy timestamps Marc Strapetz via GitGitGadget

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=xmqqmtk8a083.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=marc.strapetz@syntevo.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).