This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

3744. copy_symlink(junction, new_symlink)'s behavior is unclear

Section: 31.12.13.6 [fs.op.copy.symlink] Status: New Submitter: Nicole Mazzuca Opened: 2022-07-25 Last modified: 2022-08-23

Priority: 3

View all issues with New status.

Discussion:

The specification for copy_symlink is (31.12.13.6 [fs.op.copy.symlink]):

Effects: Equivalent to function(read_symlink(existing_symlink), new_symlink) or function(read_symlink(existing_symlink, ec), new_symlink, ec), respectively, where in each case function is create_symlink or create_directory_symlink as appropriate.

The specification for read_symlink is (31.12.13.29 [fs.op.read.symlink]):

Returns: If p resolves to a symbolic link, a path object containing the contents of that symbolic link.

And finally, the definition of a "symbolic link" is (31.12.1 [fs.general]):

A symbolic link is a type of file with the property that when the file is encountered during pathname resolution (31.12.6 [fs.class.path]), a string stored by the file is used to modify the pathname resolution.

On Unix, symlink is the only kind of symbolic link. However, on Windows, there are symbolic link files which are not symlinks (app execution aliases and junctions) — this means that read_symlink should almost certainly get the target of these files if possible. However, copy_symlink specifically requires creating a symlink, not whatever type of file was there originally. IMO, copy_symlink should require its target to be a symlink. I think the original assumption was that read_symlink would take care of that for copy_symlink; this is clearly not the case on Windows, though.

[2022-08-23; Reflector poll]

Set priority to 3 after reflector poll.

Proposed resolution: