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: Yakov Galka (ybungalobill_at_[hidden])
Date: 2011-10-27 15:04:42

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? What I do expect is that calling path.native() will return a
string ready to be passed to CreateFileW. No worries about long paths,
slashes or backslash, relative paths or other per-platform quirks. 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(), ...);

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. 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 "\\.\".

>
> > 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.

-- 
Yakov