path: root/read-cache.c
diff options
authorJohannes Schindelin <>2019-05-24 12:23:48 (GMT)
committerJunio C Hamano <>2019-05-28 19:43:43 (GMT)
commitb5a81697520621a0a1093f590d60d8e578348843 (patch)
tree3178cf24a883443984fd3796d9ca83d00022e00e /read-cache.c
parentd4c0a3ac78cf2fc16c144bf720d1451fcd1e267d (diff)
mark_fsmonitor_valid(): mark the index as changed if needed
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 extension. 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 <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'read-cache.c')
1 files changed, 2 insertions, 2 deletions
diff --git a/read-cache.c b/read-cache.c
index d3b43ae..3281676 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;