Why does filesystem::read_symlink ignore junctions?

[operatios]

I do understand that symbolic links and junctions are different, still, they both point to a target. For example, as a user, I expected to be able to successfully read both "C:\Users\All Users" (a symbolic link) and "C:\Users\Default User" (a junction).

After looking at the source code:

STL/stl/src/filesystem.cpp

Line 515 in 7f04137

if (_Buffer->_Reparse_tag == IO_REPARSE_TAG_SYMLINK) {

I see that only IO_REPARSE_TAG_SYMLINK is checked, and in case of junctions (tag value IO_REPARSE_TAG_MOUNT_POINT), an error ERROR_REPARSE_TAG_INVALID is returned. This would be fine if there existed a function like read_junction, but as far as I am aware, there is none.

This feels weird to me since other in programming languages like Python, Rust and Go you are able to successfully read both junctions and symbolic links on Windows. Here is a reference to their implementations, if needed: Python's os.readlink, Rust's fs::read_link and Go's os.Readlink.

After doing some more investigation, I found that a similar question was raised as an issue in boost: boostorg/filesystem#125 and later was fixed. I am just not sure whether this is a bug or not, since libc++'s read_symlink also does not support junctions.

Is this something that is not allowed by the C++ Standard, or is there another reason?

[fsb4000]

I see the same issue: #2077
But I don't know why it is closed as invalid...

[strega-nil-ms]

@barcharcraz points out that the standard wording for read_symlink is ([fs.op.read.symlink]/1):

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

With the definition of "symbolic link" being ([fs.general]/def:symbolic_link):

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

This says to me that junctions should be considered symbolic links, and therefore read_symlink and copy_symlink should do the obvious thing with junctions as well.

There is a question here, which is whether copy_symlink should create a junction or a directory symlink; in my opinion, the correct behavior is to create a junction.

So, to answer your question: I do believe that this is a bug.