I'm not sure whether it would be better to change [the specific test] to use robustio.RemoveAll explicitly, or to change the testing package to retry RemoveAll on Windows in case of Access is denied errors, or perhaps to change something even lower in the stack on Windows (perhaps os.RemoveAll itself?) to make it more robust.
This works around what appears to be either a kernel bug or a Go
runtime or syscall bug affecting certain Windows versions
(possibly all pre-2016?).
The retry loop is a simplified version of the one used in
cmd/go/internal/robustio. We use the same 2-second arbitrary timeout
as was used in that package, since it seems to be reliable in practice
on the affected builders. (If it proves to be too short, we can
lengthen it, within reason, in a followup CL.)
Since this puts a higher-level workaround in place, we can also revert
the lower-level workaround added to a specific test in CL 345670.
This addresses the specific occurrences of the bug for users of
(*testing.T).TempDir, but does not fix the underlying bug for Go users
outside the "testing" package (which remains open as #25965).
Trust: Bryan Mills <firstname.lastname@example.org>
Run-TryBot: Bryan Mills <email@example.com>
TryBot-Result: Gopher Robot <firstname.lastname@example.org>
Reviewed-by: Patrik Nyblom <email@example.com>
Trust: Patrik Nyblom <firstname.lastname@example.org>
Run-TryBot: Patrik Nyblom <email@example.com>