id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
298	boost::filesystem is systematically broken	libcw	beman_dawes	"{{{
As is currently discussed on the boost mailinglist,
cygwin is
supposed to support windows paths (at least, when compiled
with BOOST_WINDOWS, which is currently the default).
I understand that Beman, the author of boost::filesystem,
wants it that way.

However, boost::filesystem does not accept a path like
""/usr""
(fs::exists fails in that case), when compiled with
BOOST_WINDOWS
and it *also* doesn't accept windows paths, like
""c:/cygwin/usr"",
""C:\\cygwin\\usr"" or anything remotely 'windows' like,
because it
throws when you try to construct a fs::path with a
colon in it!

As a result, one can ONLY construct usable paths on
cygwin in the very non-portable format
""/cggdrive/c/cygwin/usr"" which is neither POSIX (on
linux the same path would be ""/usr"") nor native (the
_users_ of the application will view this path as
""C:\cygwin\usr""). It is 100% cygwin specific.  OR one
has to construct paths on
cygwin using 'native' all the time (or no_check) as
path checker,
because even windows_name doesn't work :/

Consider the following code:

#include <iostream>
#include <boost/filesystem/path.hpp>
#include <boost/filesystem/operations.hpp>

int main()
{
  try {
    boost::filesystem::path p(""C:\\cygwin\\usr"",
&boost::filesystem::windows_name);
  } catch(std::exception const& error) {
    std::cerr << ""Exception: "" << error.what() <<
std::endl;
  }
}

With the following result:

Exception: boost::filesystem::path: invalid name
""C:\cygwin\usr"" in path: ""C:\cygwin\usr""

Same thing with any other variation that starts with 'C:'.

I believe that this is a structural failure of
boost::filesystem,
revealing a major error in the design.  A re-design
seems to be in order before it can be considered to be
usable in multi-platform applications.

The most important problem with the current design is
that a single type (namely fs::path) is being used for
effectively two different types: canonical paths and
native paths.  A new design should provide a new type,
fs::native_path that cannot be mixed with the canonical
path representation.  This native_path should have
builtin checks that are native and fs::path should only
check for portability (and allow relaxation of that
when lesser OS need to be supported).

}}}"	Bugs	closed		None	None		Duplicate