Re: [boost] Possible regression in filesystem 1.31.rc1 from 1.30.2

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-01-21 14:18:58

At 06:03 AM 1/14/2004, Russell Hind wrote:
 >I have code that does this something similar to this:
 >
 >boost::filesystem::path p("C:\\Documents and Settings",
 >boost::filesystem::native);
 >     p /= "russell";
 >     p /= "My Documents";
 >
 >Under 1.30.2, this worked fine.  Under 1.31.0.rc1, this fails with
 >exception saying that "My Documents" is invalid name.  If I use the
 >filesystem::native again, then it works correctly.
 >
 >boost::filesystem::path p("C:\\Documents and Settings",
 >boost::filesystem::native);
 >     p /= "russell";
 >     p /= boost::filesystem::path("My Documents",
 >boost::filesystem::native);
 >
 >Is this intended with the 'improved checking for directory and file name
 >portability'.  Are spaces nolonger allowed in portable path names?  This
 >seems fairly limiting to me.

That's correct, spaces are not allowed by portable_name. It is composed 
from windows_name && portable_posix_name, and portable_posix_name doesn't 
allow spaces. It is following the underlying POSIX standard.

You have three choices for which name_check function to use:

* native - a good choice if your current system allows spaces, but you 
would like notification if the program is later moved to a system which 
doesn't support spaces.

* no_check - a good choice if you just don't care to name check at the 
class path level, and would prefer to let the O/S tell you the name is 
invalid when it is actually used.

* user supplied - a good choice if you want names to be portable between 
several systems, but don't care about anything other than those. Say Linux 
and Windows, which gives you more latitude that POSIX and Windows.

You have two choices as to how to apply the name_check function:

* Change the global default (but only before any use).

* On a constructor by constructor basis.

HTH,

--Beman