MAX_PATH limitation in Boost.Filesystem

Question

I want to use Boost.Filesystem library to manipulate paths, files and directories. My question is are paths longer than MAX_PATH supported?

I know that in Win32API we have workaround "\\?\" but it's not supported by basic functions like PathAppend and PathCombine.

So I'm looking for any useful info about MAX_PATH and Boost.FS.

Thanks

UPD: I care for all operation like path append, path combine, etc (I have those functions in Win32API, but they doesn't work with paths longer than MAX_PATH) For example CreateFileW and DeleteFileW both support paths longer than MAX_PATH. May Boost.FS be a replacement for Win32API utility functions such as those found in shlwapi and shell32 which often do not support long paths

Answer 1

The truth is that Windows supports paths of any length, and any path can be converted to string on windows. Adding \\?\ is required in such case, but this is the part of "make a string out of a given path" operation.

AFAIK, Boost::FileSystem does this wrong on windows.

I do not know if a fix is planned. See this about how it should be done.

Answer 2

You can manipulate any length of file system path string with or without Boost.Filesystem.

MAX_PATH is the restrictions of Windows File APIs. That is, you can not pass too long path string to Windows APIs.

For instance, remove function of the Boost.Filesystem will fail with longer than MAX_PATH length path. You want Boost.Filesystem to do something like change current directory and use relative path to prevent MAX_PATH restriction ? I don't think so its possible.

EDITED

Because Boost.Filesystem implemented upon C++ string, you don't need to worry about path length. Boost.Filesystem provide not only path string manipulation methods but also file system manipulation methods. You should avoid file system methods if the resulting path is too long.

I don't know whether or not Boost.Filesystem support Win32 Unicode path but you could convert final ANSI path to Unicode path before calling Win32 file APIs.