Note that Windows does not actually ensure the success of atomic calls to os.Rename (see also #34681).
For cmd/go we have an internal workaround in cmd/go/internal/robustio, which retries errors suspected to be spurious, although at this point we're mostly switching over to explicit file-locking rather than renaming for synchronization (see also #33974).
os.Rename is not atomic on Windows, although in practice it seems to
be mostly-atomic most of the time. At the very least, this should
substantially reduce the maintner failure rate for Windows users (if
there are any) and on the windows-amd64-longtest builder.
It would be better still to refactor netMutSource to avoid assuming
that rename is atomic and to do something else instead, like appending
to the file's final location and using the file's length or checksum
to check for completeness, or using file-locking (which does work on
Windows, at least on NTFS filesystems) instead.
(This change, in contrast, seems like the shortest path to something
that works well enough to pass on the builders.)
Trust: Bryan C. Mills <email@example.com>
Run-TryBot: Bryan C. Mills <firstname.lastname@example.org>
TryBot-Result: Go Bot <email@example.com>
Reviewed-by: Alexander Rakoczy <firstname.lastname@example.org>