[PATCH v4] ld: Rename a file on Windows fails if target already exists

[Maciej W. Rozycki]

On Fri, 1 Aug 2025, Jan Beulich wrote:

> >  This went through the whole review cycle while I was away and I had no 
> > opportunity to object.
> > 
> >  Nobody has raised the concern about losing the filesystem atomicity of 
> > rename(2) with this change, which is a regression on POSIX systems.  I'd 
> > expect a failure to rename a file for any reason to retain any original 
> > file.
> > 
> >  With this change in place the original file will be lost if the call to 
> > unlink(2) has succeeded, but the following call to rename(2) has not, 
> > which is a functional regression.  There's hardly any more irritating 
> > behaviour, as far as I'm concerned, than losing a preexisting file when a 
> > command has failed to produce its output.  And I do believe the use of 
> > rename(2) is there to prevent exactly that from happening.
> 
> As to "pre-existing file" - my understanding was that we're dealing with
> auxiliary, linker created files here.

 I know so much as the submitter included in the commit description plus 
general knowledge.

 For a linker's temporary file I'd expect a unique name to be generated 
such as with mkstemp(3) precluding the issue with a preexisting let alone 
open file or otherwise open(2) (with O_CREAT/O_TRUNC as necessary) to be 
used to write contents rather than rename(2).  The latter call is used in 
specific contexts for the very reason to retain the original file in the 
case of a failure.

  Maciej