Skip to content

<filesystem>: filesystem::read_symlink ignores junctions #2818

@strega-nil-ms

Description

@strega-nil-ms

Discussed in #2809

Originally posted by operatios June 21, 2022
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:

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?

Other questions?

  • What do we do about other types of reparse points, like app execution aliases?

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingfilesystemC++17 filesystemfixedSomething works now, yay!

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions