Re: [Boost-bugs] [Boost C++ Libraries] #8539: Windows Extended Path Prefix Suggestion

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #8539: Windows Extended Path Prefix Suggestion
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-05-03 20:05:29

#8539: Windows Extended Path Prefix Suggestion
----------------------------------+-----------------------------------------
  Reporter:  ascend4nt@…          |       Owner:  bemandawes                      
      Type:  Feature Requests     |      Status:  new                             
 Milestone:  To Be Determined     |   Component:  filesystem                      
   Version:  Boost 1.53.0         |    Severity:  Optimization                    
Resolution:                       |    Keywords:  windows filesystem extended path
----------------------------------+-----------------------------------------

Comment (by 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/8539#comment:1>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.