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

[Torbjorn SVENSSON]

Hi,

On 2025-08-01 15:34, Maciej W. Rozycki wrote:
> 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.

While I tend to agree on your thought of having a unique name generated, 
it does not appear to be implemented this way.
To my understanding, ld is doing the linking two times, in different 
modes, and then grabs one section out of the 2nd link and inserts it 
into the first binary.

Why is it done this way?
Well, here I can only speculate and I would like to avoid that. Maybe 
the original author can answer this?

In any case, I think that both the input file and the output file are to 
be considered intermediate files until the merge has been completed and 
thus, it should be fine to remove the file before the rename.
If there is a problem of removing the files this way, I think the 
original feature needs to be redesigned rather than my Windows fix is to 
be blamed. Keep in mind - without the fix for Windows, most (all?), 
GCC14 LTO tests fails.

Kind regards,
Torbjörn