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

From: Walter Landry (wlandry_at_[hidden])
Date: 2003-08-20 07:21:30

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.

Regards,
Walter Landry
wlandry_at_[hidden]