• Johannes Schindelin's avatar
    mark_fsmonitor_valid(): mark the index as changed if needed · b5a81697
    Johannes Schindelin authored
    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.
    https://docs.microsoft.com/en-us/windows/desktop/SysInfo/file-times),
    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
    https://unix.stackexchange.com/questions/11599#comment762968_11599; 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's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    b5a81697
diff-lib.c 15.2 KB