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

[Jan Beulich]

On 01.08.2025 00:16, Maciej W. Rozycki wrote:
> 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.

As to "pre-existing file" - my understanding was that we're dealing with
auxiliary, linker created files here.

Jan

>  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