#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).
Note:
See TracTickets
for help on using tickets.
