A 58% flake in a shared disk cache was a real race, found only when Linux-only CI met Windows

Zarr commits each cache entry by writing a temporary file and calling os.replace ^[11]. On POSIX, rename(2) over a file another process holds open is legal; on Windows, MoveFileEx with MOVEFILE_REPLACE_EXISTING returns ERROR_ACCESS_DENIED ^[12]. Content addressing turns that from an occasional collision into the steady state, because four workers reading the same volume derive the same keys and try to commit the same entries ^[13]. Repair the write path and the reader's open gets denied by somebody else's in-flight commit instead ^[15].

The third surface is the one that travels. The package's own LRU sweep caught only FileNotFoundError when deleting old entries, Windows raises PermissionError for a file still in use, and the sweep debited the file's bytes from the size budget anyway ^[16]. A cache whose entire job is staying under a byte ceiling was therefore under-evicting while its accounting insisted it had freed space, and that arithmetic is wrong on Linux too ^[16].

The rates deserve more attention than the headline percentage. Seven failures in twelve runs is 58.3% ^[6][7], which means a single-run CI job comes back green roughly 42% of the time ^[8]. That is the figure that explains how this lived in a hot-path component ^[9] without anyone filing it. After the fix, twelve consecutive runs were clean ^[20]. Treating runs as independent at the original rate, twelve greens in a row would turn up about once in 37,000 attempts ^[27], which is what makes that a verification rather than a lucky afternoon.

The remedy declines to branch on platform at all ^[17]. Refused writes become no-ops logged at debug, unreadable entries report as a cache miss so the outer cache refetches from source ^[17], and the sweep now skips undeletable entries without crediting their bytes and evicts the next-oldest ^[18]. The bill for that is stated rather than hidden: a full disk produces slow refetches instead of a crash ^[19]. The suite arithmetic is also tidy, 47 passed plus 2 failed is 49 before, 52 after, so the three new deterministic tests are the whole delta ^[22].

Two provenance notes. This is one self-reported account written for a contest ^[26], and the fix is a pull request against villa ^[24], not a landed upstream repair. The upstream zarr issue has been open since October with three confirmations and no fix ^[14], so any downstream project touching that store owns the rename semantics itself for now.

There is also a reason nobody had run this suite off Linux: uv sync --extra all is unresolvable on Windows and macOS because the CUDA-only cucim-cu13 dependency ships manylinux wheels only ^[25]. The same trip turned up an LRU test that stamped files 1 to 3 nanoseconds apart, which NTFS at 100 ns resolution collapses to st_mtime_ns == 0, destroying the ordering the test asserts; ext4 resolves to 1 ns, so Linux CI never noticed ^[23].