mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Johannes Schindelin via GitGitGadget" <>
Cc: "Ævar Arnfjörð Bjarmason" <>,
	"Junio C Hamano" <>,
	"Johannes Schindelin" <>
Subject: [PATCH 2/2] mark_fsmonitor_valid(): mark the index as changed if needed
Date: Fri, 24 May 2019 05:23:48 -0700 (PDT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

From: Johannes Schindelin <>

Without this bug fix, t7519's four "status doesn't detect unreported
modifications" test cases would fail occasionally (and, oddly enough,
*a lot* more frequently on Windows).

The reason is that these test cases intentionally use the side effect of
`git status` to re-write the index if any updates were detected: they
first clean the worktree, run `git status` to update the index as well
as show the output to the casual reader, then make the worktree dirty
again and expect no changes to reported if running with a mocked
fsmonitor hook.

The problem with this strategy was that the index was written during
said `git status` on the clean worktree for the *wrong* reason: not
because the index was marked as changed (it wasn't), but because the
recorded mtimes were racy with the index' own mtime.

As the mtime granularity on Windows is 100 nanoseconds (see e.g.,
the mtimes of the files are often enough *not* racy with the index', so
that that `git status` call currently does not always update the index
(including the fsmonitor extension), causing the test case to fail.

The obvious fix: if we change *any* index entry's `CE_FSMONITOR_VALID`
flag, we should also mark the index as changed. That will cause the
index to be written upon `git status`, *including* an updated fsmonitor

Side note: Even though the reader might think that the t7519 issue
should be *much* more prevalent on Linux, given that the ext4 filesystem
(that seems to be used by every Linux distribution) stores mtimes in
nanosecond precision. However, ext4 uses `current_kernel_time()` (see; it
is *amazingly* hard to find any proper source of information about such
ext4 questions) whose accuracy seems to depend on many factors but is
safely worse than the 100-nanosecond granularity of NTFS (again, it is
*horribly* hard to find anything remotely authoritative about this
question). So it seems that the racy index condition that hid the bug
fixed by this patch simply is a lot more likely on Linux than on
Windows. But not impossible ;-)

Signed-off-by: Johannes Schindelin <>
 diff-lib.c      | 2 +-
 fsmonitor.h     | 5 +++--
 preload-index.c | 2 +-
 read-cache.c    | 4 ++--
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/diff-lib.c b/diff-lib.c
index a838c219ec..61812f48c2 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -232,7 +232,7 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
 		if (!changed && !dirty_submodule) {
-			mark_fsmonitor_valid(ce);
+			mark_fsmonitor_valid(istate, ce);
 			if (!revs->diffopt.flags.find_copies_harder)
diff --git a/fsmonitor.h b/fsmonitor.h
index 8489fa3244..739318ab6d 100644
--- a/fsmonitor.h
+++ b/fsmonitor.h
@@ -49,9 +49,10 @@ void refresh_fsmonitor(struct index_state *istate);
  * called any time the cache entry has been updated to reflect the
  * current state of the file on disk.
-static inline void mark_fsmonitor_valid(struct cache_entry *ce)
+static inline void mark_fsmonitor_valid(struct index_state *istate, struct cache_entry *ce)
-	if (core_fsmonitor) {
+	if (core_fsmonitor && !(ce->ce_flags & CE_FSMONITOR_VALID)) {
+		istate->cache_changed = 1;
 		ce->ce_flags |= CE_FSMONITOR_VALID;
 		trace_printf_key(&trace_fsmonitor, "mark_fsmonitor_clean '%s'", ce->name);
diff --git a/preload-index.c b/preload-index.c
index e73600ee78..ed6eaa4738 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -78,7 +78,7 @@ static void *preload_thread(void *_data)
 		if (ie_match_stat(index, ce, &st, CE_MATCH_RACY_IS_DIRTY|CE_MATCH_IGNORE_FSMONITOR))
-		mark_fsmonitor_valid(ce);
+		mark_fsmonitor_valid(index, ce);
 	} while (--nr > 0);
 	if (p->progress) {
 		struct progress_data *pd = p->progress;
diff --git a/read-cache.c b/read-cache.c
index d3b43ae3ba..32816763bd 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -204,7 +204,7 @@ void fill_stat_cache_info(struct index_state *istate, struct cache_entry *ce, st
 	if (S_ISREG(st->st_mode)) {
-		mark_fsmonitor_valid(ce);
+		mark_fsmonitor_valid(istate, ce);
@@ -1432,7 +1432,7 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
 			if (!S_ISGITLINK(ce->ce_mode)) {
-				mark_fsmonitor_valid(ce);
+				mark_fsmonitor_valid(istate, ce);
 			return ce;

      parent reply	other threads:[~2019-05-24 12:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24 12:23 [PATCH 0/2] Fix racy fsmonitor Johannes Schindelin via GitGitGadget
2019-05-24 12:23 ` [PATCH 1/2] fill_stat_cache_info(): prepare for an fsmonitor fix Johannes Schindelin via GitGitGadget
2019-05-24 12:23 ` Johannes Schindelin via GitGitGadget [this message]

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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

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