Windows Extended Path Prefix Suggestion

[ascend4nt@…]

With the Windows extended path prefix:

\\?\

It might make sense if the path class pre-allocates 4 extra characters for paths and stores the actual path at position m_pathname[4] in the string. When a path exceeds MAX_PATH, the path functions could write the extended path prefix at m_pathname[0] and pass that along to the Windows API. It may make sense to return this as something like extended_path() as well.

The only problems in dealing with extended paths are that there can be no relative path (. and ..) segments and no forward slashes.

I realize this may require alot of logic changes in the code (shifting read/write locations); however it could cut down on additional Windows-specific wrappers around the path class.

[ascend4nt@…]

Actually the prefix of 4 characters doesn't work with UNC (network) paths, since this requires additional characters. The basic UNC path looks like:

\\NetPC\share

However, with extended-length paths, it would look like this:

\\?\UNC\NetPC\share

Not only is there an additional 3 characters (UNC) prefixing the path, but the Windows API also requires that one of the backslashes prefixing the server ("NetPC" in this example) be removed.

The only maintainable way to handle this would be to create a new string which is stripped of the first backslash of a UNC name and prefixed with the above extended-path UNC prefix.

There are other ways to dynamically handle this, but they require maintaining internal states, returning a dynamic index into the string buffer, or overwriting one of the backslashes internally when Windows APIs are called. This leads to less maintainable, 'hacky' type of code. (although potentially more efficient).

The 'extended_path()' call I mentioned above would make more sense if it just created a new string on the fly with the extended prefix and a stripped backslash. This would require analysis of the string to determine a path type prior to returning the extended path, of course.

Meh, its becoming clearer to me that the path class isn't suited for extended-path names due to all the extra handling involved for a single poorly implemented API (Windows). To do it right, the class would need to examine incoming paths for extended-path prefixes or UNC prefixes as well as modify strings on the fly that exceed MAX_PATH chars, including 'flipping' forward slashes and possibly adjusting string based on relative path strings ('.' and ".."). This all would make path more complex and less 'low-level' unfortunately.