Repository navigation
<filesystem>: Does it naturally support all functions with a long path (>260) on Windows? #1921
Description
Long Path Support (>260 Characters) with MSVC STL <filesystem>
Hello, I'm filing this issue to ask about the information of Windows Long Path Support in the <filesystem> STL.
Traditionally, Windows doesn't support long path (>260 characters) before Windows 10, version 1607. This was explained here.
There was no information on the Internet about whether the current implementation of <filesystem> supports long paths. I have checked the <filesystem> documentation and searched on Google. The only related information I found was this and this. But they are relatively old because this repo went to public in 2019.
Traditionally, msvc's STL before <filesystem> didn't support long paths. However, when I looked into the implementation of <filesystem>, I think it does use the OS API supporting long paths. So just to confirm what I found, I have a few questions:
- Does the current
<filesystem>support long paths on Windows?- If so, what is the minimum version of msvc compiler supporting that?
- Whether all functions/classes of
<filesystem>support long paths?- I asked this because I don't see this behavior is verified in the tests: I only saw a few usage of
longSuffixin https://github.com/microsoft/STL/blob/main/tests/std/tests/P0218R1_filesystem/test.cpp. And they are not covering major functionalities.
- I asked this because I don't see this behavior is verified in the tests: I only saw a few usage of
- Whether people need to manually convert a path to its UNC form in order to make
<filesystem>support long paths? Or does<filesystem>convert the long path to its UNC path for users automatically?- i.e. what people should do in order to utilize
<filesystem>to support windows long paths. It would be good to have a simple example/tutorial.
- i.e. what people should do in order to utilize
- Since
<filesystem>only handles file operations, I was wondering if the file I/O of the current STL also supports long paths.- i.e. whether the C API or stream libraries support file open/read/write with a long path?
Finally, it would be really great if the documentation of <filesystem> can add more information about long path support.
Thanks a lot!
Eric
Activity
[-]<filesystem> - Does it naturally support all functions with a long path (>260) on Windows?[/-][+]<filesystem>: Does it naturally support all functions with a long path (>260) on Windows?[/+]StephanTLavavej commentedon May 15, 2021
Yes, if and only if the OS support for long paths is enabled.
(Note that this applies to Standard C++17
<filesystem>only. The non-Standard<experimental/filesystem>cannot support long paths, one of the many reasons why it's deprecated and will be removed.)The initial implementation of
<filesystem>in VS 2017 15.7.They should all support long paths.
Filed #1923 to track this, thanks.
No, users shouldn't do this.
No,
<filesystem>doesn't do this.What
<filesystem>does is pass long paths to the OS unchanged (using flexible-length strings, never assuming that they fit inMAX_PATH- which is what doomed<experimental/filesystem>).While
<filesystem>also supports UNC paths (avoiding getting confused by the\\?\at the beginning), UNC paths have surprising behavior and should not be used except by expert users who know exactly what they're doing. In particular, this disables "normalization", like trimming whitespace. That's why we don't attempt to support long paths on older OSes by converting them to UNC paths.This should also work, if and only if OS support for long paths is enabled. This is because
ofstreametc. call thefopenfamily (_fsopen/_wfsopenetc.) which eventually callsCreateFileW, and we avoid interfering with long paths along the way.Filed https://github.com/MicrosoftDocs/cpp-docs/issues/3138 to track that, thanks! 😸
eric-zheng commentedon May 15, 2021
Thanks a lot Stephan T. Lavavej (@StephanTLavavej) for your detailed explanation! And thank you for creating the two new issues. I'll create a set of tests related to long path support in our codebase and possibly contribute to the issue you just filed in the future.
Thanks to the open-sourced STL project and we were able to get timely responses!
Eric