Re: [boost] Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)

Subject: Re: [boost] Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-10-27 16:26:32

On Thu, Oct 27, 2011 at 3:04 PM, Yakov Galka <ybungalobill_at_[hidden]> wrote:
> On Wed, Oct 26, 2011 at 22:47, Beman Dawes <bdawes_at_[hidden]> wrote:
>
>> On Wed, Oct 26, 2011 at 6:24 AM, Yakov Galka <ybungalobill_at_[hidden]>
>> wrote:
>>
>> > Personally I think that boost::filesystem::paths are a sad joke, it's a
>> pity
>> > they're heading to the standard. Although the OS-part is definitely good,
>> > the way path class is design isn't suitable for paths outside the unix
>> > world.
>>
>> Could you explain that a bit further? Since class path is used all the
>> time for paths outside the Unix world, I'm curious to know what your
>> concerns are.
>>
>
> Give me some time to write a constructive criticism. Some issues I raise
> below.
>
>  > you still cannot use long paths
>> > on windows (longer than MAX_PATH), although they are supported by the OS.
>>
>> There is one ticket outstanding,
>> http://svn.boost.org/trac/boost/ticket/5448, that is somewhat related
>> to PAX_PATH limitations. The objective is to support any path that is
>> acceptable to the operating system, and that includes better support
>> for long paths.
>>
>
> I know this ticket. Your objective is useless. Seems Bjarne is right about
> the composition of the committee. Have you done a survey among the users of
> the library?

I hear from users of the library regularly. They mirror the rest of
the Boost population; very roughly one third use Unix-like systems and
two thirds use Windows. Once Microsoft ships the Dinkumware
implementation of the library (based on V2) with VC++ 211, the
percentage of Windows users will presumably increase.

> What I do expect is that calling path.native() will return a
> string ready to be passed to CreateFileW.

Yes, that's what it does. Regardless of the operating system, the
contents of  path.native(), or more to the point, path.c_str(), is
exactly as was passed into the path originally. That's important in
case it is one of the implementation defined strings - it isn't the
job of path to adjust the string.

> No worries about long paths,
> slashes or backslash, relative paths or other per-platform quirks.

Right.

> Currently
> I must write something like this:
>
> path p = get_some_path();
> p = system_complete(p); // according to msdn not guaranteed to work for long
> paths. Fortunately it does in practice.
> std::wstring q = p.native();
> if(starts_with(q, L"\\\\"))
>    q = "\\\\?\\UNC\\" + q.substr(2);
> else
>    q = "\\\\?\\" + q;
> // doesn't handle \\.\....
> CreateFileW(q.c_str(), ...);

If you have to write any of that, it is a bug in the library
implementation. That's the point of
http://svn.boost.org/trac/boost/ticket/5448 - to be sure that the
odd-ball, implementation defined syntaxes work. Not just for Windows,
but for POSIX too.

> The problem is more serious when we observe that the \\?\ and \\.\ syntax is
> a detail of implementation. For example we DON'T want the user to be able to
> input a \\.\ path. We also prefer the user to don't see \\?\ at all.

Who is the "we" here? There was a time very early on in V1 where I
though the Filesystem library path should only accept "approved"
forms. Users, and a lot of them at that, let me know loud and clear
that they didn't want to be nannied. If they passed in a given native
string, that's want they wanted to get passed to the operating system.
 If they passed in a given generic string, that's want they wanted to
get passed to the operating system, modulo only any changes absolutely
required by the O/S (which means none on either POSIX or Windows).

> In fact
> there are two path syntaxes on windows:
> 1) User paths: can have slashes and backslashes. They start with "\\x",
> "\x", "x:" or "x" (more or less).
> 2) System paths: only backslashes supported in general, can't be relative,
> may start with "\\?\" and "\\.\".

Yes, and there is no intention for the Filesystem library to intervene
if the user gets it wrong, such as by exceeding a maximum length
mandated by the operating system or file system.

>> > Moreover, judging by the last fixes to the library, it looks like Beman
>> > wants to shift the burden of this on the user of the library, instead of
>> > implementing something that works transparently.
>>
>> Which fixes are bothering you:-?
>>
>
> I was talking about revision 71157.

Ah! So you want to hide the various implementation defined formats?

--Beman