Boost logo

Boost :

From: (noreply_at_[hidden])
Date: 2004-08-19 07:01:17

Bugs item #1012135, was opened at 2004-08-19 14:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Carlo Wood (libcw)
Assigned to: Nobody/Anonymous (nobody)
Summary: boost::filesystem is systematically broken

Initial Comment:
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
(fs::exists fails in that case), when compiled with
and it *also* doesn't accept windows paths, like
"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",
  } catch(std::exception const& error) {
    std::cerr << "Exception: " << error.what() <<

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


You can respond by visiting:

SF.Net email is sponsored by price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
Boost-bugs mailing list

Boost list run by bdawes at, gregod at, cpdaniel at, john at