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 :-(
