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]>
>> > Personally I think that boost::filesystem::paths are a sad joke, it's a
>> > 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
> > 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.
> 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);
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk