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_name
isC:
and theroot_path
isC:\
which are both valid paths but - for
\\?\C:\tmp\test.txt
they 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::filesystem
has 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::filesystem
on MSVC I getFor
boost::filesystem
I get: