Windows: mtime encoding split makes the incremental classifier see every file as changed #1917

Two Windows-only comparisons can never match, because the two sides encode file mtime differently. Found while diagnosing a Windows-only failure in #1905, where the same split had a third instance (fixed there); these two are pre-existing and were deliberately left alone because fixing them changes broad indexing behaviour.

The encoding split

file_hashes.mtime_ns is stamped by semantic_manifest_hash_file → cbm_path_info_utf8 (pipeline_incremental.c:186), whose Windows branch derives the value from ftLastWriteTime — 100-nanosecond FILETIME ticks (compat_fs.c:146-152).

Both sites below re-read the same files with a stat-family call and encode st_mtime * 1e9 — whole seconds.

The two agree only when a file's write time lands exactly on a second boundary. On POSIX there is no split at all: both paths read st_mtim nanoseconds.

Site 1 — the incremental classifier sees every file as changed

src/pipeline/pipeline_incremental.c:693:

if (stat_mtime_ns(&st) != h->mtime_ns || st.st_size != h->size) {
    changed[i] = true;

On Windows the left side is whole seconds and the right side is FILETIME ticks, so this is true for essentially every file. Every incremental reindex on Windows re-parses the entire project.

It fails safe — over-reporting change can only cost time, never correctness — which is why this has gone unnoticed. But it means Windows users have effectively never had incremental indexing, only a full reindex wearing its name. Given how much of this project's performance work targets the warm path (delta merge, closure repair, the 121.7s kernel warm figure), that is a substantial platform gap hiding behind a benign failure mode.

Site 2 — check_index_coverage reports metadata_changed for everything

src/mcp/mcp.c (check_index_coverage, the row-vs-disk comparison) has the same shape, so on Windows it reports metadata_changed for every file it inspects. That is a user-visible wrong answer from a tool whose entire job is telling you whether the index is current.

Why this is filed rather than fixed

Both changes alter broad indexing behaviour. Site 1 in particular would flip Windows from "always full reindex" to "genuinely incremental", which is a real behavioural change deserving its own measurement — and a bug that has been failing safe for a long time should not be fixed as a rider on an unrelated PR.

Suggested shape

Read the disk side through cbm_path_info_utf8 — the same function that wrote the row — so there is no encoding to keep in sync. That is what #1905 does for the reconcile path, and both sites there now carry comments pinning the asymmetry where a whole-second stat is deliberately retained.

Note the two encodings cannot simply be unified everywhere: restamped rows are consumed by these very call sites, so changing one side without the other moves the mismatch rather than removing it. Whichever site is fixed first should assert its own round-trip.

Verification note

The split is visible in both code paths and was reproduced on macOS by emulating the Windows encoding (truncating the disk side to whole seconds), which reproduced #1905's Windows CI signature exactly — 7 failing sites, matching. It has not been executed on Windows; that confirmation is still outstanding.