Re: [boost] Re: Filesystem portable path rationale and use-cases

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

At 08:21 AM 8/20/2003, Walter Landry wrote:
 >David Abrahams <dave_at_[hidden]> wrote:
 >> Walter Landry <wlandry_at_[hidden]> writes:
 >>
 >> > Brian Gray <briangray_at_[hidden]> wrote:
 >> >> Should we (do we?) have some spreadsheet enumerating various 
filesystem
 >
 >> >> features, quirks, and limitations for whatever systems we can find, 
and
 >
 >> >> using that as a reference regarding how to organize features like
 >> >> paths, file references, forks, or whatever else?  It might help us 
to
 >> >> back out of the code and re-examine the problem domain regardless of 

 >> >> the current state of Boost.
 >> >
 >> > I've been thinking that maybe the best way to provide for portable
 >> > paths is to have a bunch of flags that you can set.  So when you push
 >> > something onto Beman's singleton stack, you can, for example, set the
 >> > NTFS and VMS flags if you only care about those filesystems.
 >> >
 >> > However, that makes it difficult to extend to customized portability
 >> > restrictions.  That might require some kind of function stack within
 >> > each element of the singleton stack.  Then you can push the NTFS and
 >> > VMS checkers onto that stack within the stack.
 >>
 >> I _really_ hope we don't have any singleton stack which affects path
 >> validation.  It sounds like a nightmare for any application involving
 >> threads.
 >
 >I think I finally understand what the problems with multiple threads
 >are.  You are worried that one thread's portability checking will be
 >changed midstream by another thead.  Sounds hairy.  So one solution is
 >to make the portability checking local to a thread.  I don't have a
 >feel for how to implement that, and it does seem to introduce
 >complexity where it isn't always needed.

If the only mechanism for identifying name checkers was via default 
modification, we would have to use some sort of singleton stack or list, 
and would have to protect it from self-induced race conditions. But the 
default mechanism is just an added convenience, although an important one. 
Explicitly supplying a name checker in the path constructor is always 
available.  As long as the default mechanism covers the bulk of the use 
cases, and can be tailored to the best default for each program, it really 
doesn't seem unreasonable to ask people to use constructor arguments for 
less common cases. I think when I proposed the singleton stack that I had 
lost sight of the fact that defaults aren't the only way to specify a 
checker.

There certainly is a legitimate need to easily combine two checkers, as in 
your NTFS and VMS example.

Is it too much to ask people to write the following?

bool NTFS_and_VMS( const std::string & name )
{
   return boost::filesystem::NTFS_check(name)
       && boost::filesystem::VMS_check(name);
}

int main()
{
   boost::filesystem::set_name_checker( NTFS_and_VMS );
   ...

My initial thought is to do a prototype implementation (and documentation) 
to get some experience, without supplying any additional mechanism.

--Beman