windows: resume reads the session file through a second handle under its own mandatory LockFileEx — reachable once #501 builds windows; the lock is #378 filelock, and there was no windows binary before, not a stub

[santoshkumarradha]

Observable failure (expected, not yet run)

On windows, openSessionFile (internal/session/sessionfile.go, around line 1132 at #501's tip 2dfad92) takes an exclusive LockFileEx on byte 0 of the session file, then replaySessionFile (around line 1141) opens a second handle on the same file and reads that byte. Windows byte-range locks are mandatory, so that read should fail with ERROR_LOCK_VIOLATION; on unix flock is advisory and the same shape works. The same read-under-own-lock shape reaches tui3's home transcript reads.

Where it comes from

Not introduced by #501 (which only makes cmd/aforge build on windows, with unix behaviour byte-for-byte unchanged). It is inherited from the internal/filelock contract #378 shipped. Issue #96 flagged the advisory/mandatory gap as "worth a glance rather than an assumption"; this is the glance.

Fix shape

Lock a byte past EOF (or a dedicated lock file) so the lock never covers a byte anything reads, or read through the locked handle. Either way a windows-native test is owed: nothing in CI runs a windows binary; the six-target cross build only compiles it.

Found by the lane preparing #501 for landing on 2026-09-03; filed and queued under the freeze, not started.

---

Drafted with CodeAF · reviewed and owned by the author

[santoshkumarradha]

Precision on provenance, for the record: before #501 internal/session did not compile on windows at all (unix.Flock since 2026-08-15), so there was no windows binary and no stub; the first windows binary is #501, and the lock it takes is internal/filelock's LockFileEx from #378. So the failure is not inherited from a working windows path; it becomes reachable the moment #501 lands, with semantics #378 chose.