On Sun, Jun 28, 2026 at 04:18:07AM -0400, Jeff King wrote:

I tried with a vfat mount, and it also works: we don't have nanoseconds
either before or after. That makes sense, and implies that modern Linux
will always be OK (because it limits the cached VFS response to what the
underlying filesystem can handle).

So...maybe this is just a non-issue these days, at least on Linux?

Oh, I also ran across this old thread:

  https://public-inbox.org/git/5605D88A.20104%40gmail.com/

that implies similar:

  * In-core file times may not be properly rounded to on-disk
    precision, causing spurious file time changes when the cache is
    refreshed from disk. This was fixed for typical Unix file systems
    in kernel 2.6.11. The fix for CEPH, CIFS, NTFS, UFS and FUSE will
    be in kernel 4.3. There's no fix for FAT-based file systems yet.

I also tested with CIFS on my system and it is fine. It looks like FAT
systems were fixed since 2015. ;)

But there is another interesting question raised there, which is how
different implementations may interact (e.g., two versions of Git
without and without USE_NSEC, or JGit which may have to use
millisecond-resolution APIs, etc). It should all work correctly as long
as each implementation consistently uses its own resolution (so JGit
would have to compare in millisecond-space and treat ties as racy). And
I think that is _probably_ what is happening now, since we already store
nanoseconds unconditionally (and only use them with USE_NSEC).

Though the opposite case is a performance problem but not a correctness
one: if JGit writes out an index with milliseconds and USE_NSEC Git
tries to read it, we will consider everything stat-dirty and re-read the
contents.

I don't know if these would be a problem in practice or not, but it's an
interesting potential gotcha. And one that nobody may have noticed,
because probably hardly anybody bothers to build with USE_NSEC now.

-Peff