Opened 18 years ago

Closed 17 years ago

Last modified 17 years ago

#298 closed Bugs (Duplicate)

boost::filesystem is systematically broken

Reported by: libcw Owned by: beman_dawes
Milestone: Component: None
Version: None Severity:
Keywords: Cc:

Description

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

Change History (2)

comment:1 by beman_dawes, 17 years ago

Status: assignedclosed

comment:2 by beman_dawes, 17 years ago

Logged In: YES 
user_id=51042

See the comment attached to bug report 1010681
Note: See TracTickets for help on using tickets.