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 `symlink`s (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: