[Bug libstdc++/119289] Incorrect behavior of std::filesystem::copy() with none options and the destination link to non-existent file

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119289

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2025-03-14
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
POSIX says:

In general, the open() function follows the symbolic link if path names a
symbolic link. However, the open() function, when called with O_CREAT and
O_EXCL, is required to fail with [EEXIST] if path names an existing symbolic
link, even if the symbolic link refers to a nonexistent file. This behavior is
required so that privileged applications can create a new file in a known
location without the possibility that a symbolic link might cause the file to
be created in a different location.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/open.html#tag_17_372_08

Which is indeed what we're seeing here. So the bug seems to be that libstdc++
should not use O_EXCL when 'to' is a dangling symlink, or we should handle the
EEXIST by using symlink_status to check if it's a dangling symlink and then
either try open again without O_EXCL (or use read_symlink in a loop until we
find the non-existent target of that symlink, and then open that name).

This means filesystem::copy_file should have precisely the flaw that O_EXCL
avoids :-(