Re: [boost] Re: boost::filesystem file restrictions

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-18 15:21:05

At 10:59 AM 8/18/2003, David Abrahams wrote:

 >Beman Dawes <bdawes_at_[hidden]> writes:
 >
 >> Yes. Plus there are some other issues.
 >>
 >> The actual interface would include boost::filesystem::path
 >> constructors which take an additional argument to explicitly specify a
 >> name checker function. In working out use cases, it seems that
 >> temporary overrides of the default function are best handled via these
 >> constructors. That leaves only the case of wishing to permanently
 >> replace the default function, and the simpler approach you are talking
 >> about would be better for that.
 >>
 >> For safety, such a set_legal_name_policy() would use the
 >> write-once-before-read idiom to avoid a dangerous global
 >> variable. (I'm actually thinking of "name_check" for the type, and
 >> "set_name_check" for the function name.)
 >>
 >> I'm about to post a message asking for opinions on the details of the
 >> policy function pointer or object.
 >
 >This starts to align with what I've been thinking.  Every path object
 >could maintain a chain of checkers, and combinations of path objects
 >(e.g. via operator/) would use the union of the checkers of their
 >components, so that checking would never become less-restrictive
 >silently.

That is more machinery than is needed. It would be a nice design for a 
system that had to revisit elements, but for that isn't required here.

When I was first working with designs for error checking, I tried a lot of 
similar schemes. Eventually I realized that treating name validity as an 
invariant established at construction was much simpler and performed quite 
well. It doesn't require keeping a chain of checkers. It performs the 
checking at the point in the calling program where knowledge of what is 
valid is present.

 >  Of course, though I think this goes against the grain of
 >the library, I believe the default checker should always be the for
 >the native platform.

Because the native platform may support several different file systems 
within the same directory tree, it isn't possible to perform a full and 
correct lexical (inspection of the name only) check for the native 
platform. You in effect have to try the path and see if the operating 
system accepts it. What the lexical level name check done by class path is 
trying to do is early detection of gross naming errors.

A specific example might help. Say you are working on a Linux platform. It 
supports a really wide range of characters in names. But you know the code 
sometimes will run on Windows, so you would like to check automatically 
that some directory tree you create doesn't violate Windows naming 
conventions. You do this by specifying a Windows name checker (which 
disallows a bunch of special characters). This will prevent your program 
from inadvertently using the special characters that Windows always 
disallows.

Now when the program actually runs on a Windows box, a native path may be 
given (say by operator input) as the root, and then the relative portions 
your program adds get tacked on. If the operator supplied root happens to 
be a CD ISO-9660 file system, your carefully chosen relative names may 
fail, because the ISO-9660 names are way more restricted that general 
Windows names.

In that case, the attempt at early detection was a failure; the name 
checker did no good. But a lot of real-world errors will be detected early, 
so I don't see the name checking as a failure. It just is a partial check, 
not an iron-clad guarantee. A useful axillary mechanism, but not the main 
show.

But because it can't be an iron-clad guarantee, I'd prefer not to build an 
even mildly complex mechanism to support it. Particularly since some 
programmers will disable it anyhow.

--Beman