fix(win32): add 50ms tolerance for NTFS mtime fuzziness in FileTime assert

[Hona]

Summary

• NTFS mtime fuzziness (~50ms) caused spurious "file modified since last read" errors on Windows. Add a 50ms tolerance to the timestamp comparison so async filesystem flushing doesn't trigger false positives.

Fixes flaky tool.edit and tool.write Windows unit test failures. Split out from #14742.

[Copilot]

Pull request overview

Adjusts FileTime.assert() to reduce flaky Windows test failures caused by NTFS mtime granularity / async flush timing, preventing false “file modified since last read” errors when using overwrite-style tools.

Changes:

• Add a 50ms tolerance when comparing file mtime to the stored “last read” timestamp in FileTime.assert().

Comments suppressed due to low confidence (2)

packages/opencode/src/file/time.ts:65

• The 50ms tolerance is described as Windows/NTFS-specific, but it currently applies on all platforms. That weakens the overwrite-safety check on Linux/macOS by allowing external modifications within 50ms after a read to go undetected. Consider making the tolerance conditional (e.g., process.platform === "win32" ? 50 : 0) or otherwise limiting it to the platforms/filesystems that need it.

    // Allow a 50ms tolerance for Windows NTFS timestamp fuzziness / async flushing
    if (mtime && mtime.getTime() > time.getTime() + 50) {

packages/opencode/src/file/time.ts:65

• This introduces new behavior (tolerating small mtime drift) but there’s no unit test asserting that a modification time within the tolerance does not trigger the "modified since last read" error. Adding a test (likely by stubbing Filesystem.stat to return an mtime slightly after the stored read time) would prevent regressions and make the Windows flake fix more robust.

    // Allow a 50ms tolerance for Windows NTFS timestamp fuzziness / async flushing
    if (mtime && mtime.getTime() > time.getTime() + 50) {

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.