boost::filesystem fails in posix with files containing ':'

[nobody]

(Too bad one can't mail to the mailing lists without
registering first. My email is flux-boost@inside.org.)

I have Boost 1.30.0-4 from Debian GNU/Linux.

The exception I'm getting for merely handling such a path:

  boost::filesystem::path: invalid name "foo:_Kuu" in
path: "foo:_Kuu"

The problem seems to stem from
libs/filesystem/path_posix_windows.cpp, where a
function called generic_name checks against a ton of
letters that pose a problem in Windows - however, the
only characters not legal in a Unix-filename are / and
\0.         

Is it really a job of this class to check for
path-validity anyway?    Well I suppose that has been
discussed already ;).

The function checks also for spaces at the beginning
and at the end of  a segment, surely one would imagine
they are legal in Windows too?-o

I didn't fully investigate the matter, but ///tmp///foo
is also a legal unix-path, albeit redundant, I hope
that doesn't pose a problem?

My hackish fix:
               
    bool generic_name( const std::string & name )
    {                                            
#ifdef BOOST_WINDOWS
      return name.size() != 0
        && name.find_first_of( invalid_generic ) ==
std::string::npos
        && name != "."
        && name != ".."
        && *name.begin() != ' '
        && *(name.end()-1) != ' ';
#else
      return name.size() != 0
        && name != "."
        && name != "..";
#endif
    } 

[Vladimir Prus]

Logged In: YES 
user_id=321498

Hi, 
First, you did not provide the test case which is failing for 
you. Second, are you sure you're passing "fs::native" as 
second parameter to 'path' ctor? 

[nobody]

Logged In: NO 

A test-case would be:

#include <boost/filesystem/operations.hpp>
int main() { boost::filesystem::path path(":"); }

(which dies on unhandled exception, ie. SIGABRT, on Debian)

However, your point about missing second argument of
boost::filesystem:native is correct, and removes the
exception ;). 

This brings me to read the specification, which correctly
defines the range of allowed characters, but, I must wonder
why would not all legal filenames be accepted by default.
Also, why would this default-path-format not be listed in
the enumeration path_format.

[nobody]

Logged In: NO 

I think that there's no need to list this style in enumeration, 
since you have single-parameter ctor. As for generic grammar 
rationale, Beman (the library author), might know better, but 
I think it's a good thing. Say, if you create a name with "*" 
and pass it to system, you can be surprised. The current 
semantic prevents you from unintentionally using unportable 
syntax. 
 
In case you'd like to continue this discussion, I think mailing 
list would be better. 

[beman_dawes]

Logged In: YES 
user_id=51042

Poster was apparently not specifying native ctor argument.

Note that the complaint about being excessively nannyish
will be resolved in 1.34.0