std::filesystem::path doesn't seem to be aware of the windows long path magic prefix. Is this per design or is there a mode/flag/compiler switch/3rd party library which can be used?
f.e.
- for a path like
C:\temp\test.txt, theroot_nameisC:and theroot_pathisC:\which are both valid paths but - for
\\?\C:\tmp\test.txtthey are\\?and\\?\
I hoped that they would be C: and C:\ as well because \\?\ is not a path but just a tag used to work around the legacy windows 260 char path limit.
As mentioned in the comments above, the source code of the Microsoft STL shows that the current behavior is intentional for UNC (Uniform Naming Convention) paths and that there is no "magic compiler switch" to change this. Moreover, it seems that UNC paths should not be used with
std::filesystem, as implied by this github post. There is also an open issue that requests a change of behavior.Since the OP is ok with 3rd party libraries:
boost::filesystemhas special code on Windows builds for UNC paths and gives results that are closer to what is expected.Trying it out with the following code (adapted from the original post):
For
std::filesystemon MSVC I getFor
boost::filesystemI get: