Well, if the suggested idiom doesn't work under Windows, I'd argue that either Windows (or possibly Perl) is broken in that regard.

Good luck getting Bill Gates or p5p to acknowledge that their unlink is broken. ;-) The Perl documentation for the unlink function is annoyingly vague: "Deletes a list of files. Returns the number of files successfully deleted.".

The POSIX unlink semantics are clearer, if difficult to implement on non Unix systems, as noted in djgpp POSIX unlink specification:

The POSIX specification requires this removal to be delayed until the file is no longer open. Due to problems with the underlying operating systems, this implementation of unlink does not fully comply with the specs; if the file you want to unlink is open, you're asking for trouble -- how much trouble depends on the underlying OS.

I might add that the ANSI C remove function does not appear to mandate POSIX semantics: calling remove on an open file on Linux works (a la POSIX unlink), while on Windows it fails.

BTW, I found a related discussion of atomic file update in the "Atomic in-place edit" section in This Week on perl5-porters (18-24 November 2002). Not sure if anything was resolved, however. (Update: apart from MJD submitting a Bug report for the Universe :-).