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

[Maciej W. Rozycki]

On Tue, 22 Jul 2025, Torbjorn SVENSSON wrote:

> > Okay for master (iirc Nick gave his okay for the branch already) with a
> > few more cosmetics done:
> 
> Fixed the cosmetics and pushed as 233cd5946413108bf4902b22a9cb23ad0a468f5e to
> master and 888f048f72609f716dfc6da21f766c22e5866fad to binutils-2_45 branch.

 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.

 It seems to me that this Windows quirk of rename(2) ought to be handled 
by a portability layer, perhaps gnulib, by simulating POSIX semantics on 
the Windows host only, such as by giving any existing file a temporary 
name and either deleting it or renaming back depending on the success or 
the failure of the intended call to rename(2).

 Of course it wouldn't give filesystem atomicity on Windows, but there is 
none anyway, not at least with this system call, and it wouldn't regress 
proper POSIX systems and would fulfil the principle of least surprise on 
Windows as well (and work everywhere rather than this specific code path 
only).

 I have no concerns as to closing the original file/BFD, which also means 
these should have been two separate changes, as they address a different 
issue each.

  Maciej