RE: [boost] Re: Design for a file system library

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-23 20:02:48

At 04:55 PM 2/23/2002, Jeff Garland wrote:
 >> Jeff,
 >>
 >> In the document (which I really should have called Requirements and
 >General
 >> Specs, to distinguish from detailed design) I didn't want to get into
 >> details to the point where I specified which (or all) of these would be
 >> valid:
 >
 >Right.  And as the document stands there is no requirement to be able to
 >distinguish a dirpath from a filepath.  Both you and Jan both pointed me 
to
 >the
 >'attributes' mechanism, but that is an optional extension, rendering it
 >useless
 >for writing portable directory and file management programs.  My claim
 >(obviously not well communicated) is that the spec falls short because I
 >cannot
 >write portable traversal/management program without being able to
 >distinguish
 >files from directories portably.  So I believe it needs to be in the spec 

 >to
 >meet requirement #1 "write portable script-style file system 
operations.".

OK, I've changed the doc to make that clearer.

 >
 >
 >>    //  get() and remove() on names
 >>    for (dir_it i ("/usr/junk"); i != dir_it (); ++i)
 >>    {
 >>      if (!get <is_directory> (compose ("/usr/junk", *i)))
 >>      {
 >>        remove (compose ("/usr/junk", *i));
 >>      }
 >>    }
 >>
 >>    //  get() and remove() on iterators
 >>    for (dir_it i ("/usr/junk"); i != dir_it (); ++i)
 >>    {
 >>      if (!get <is_directory> (i))
 >>      {
 >>        remove (i);
 >>      }
 >>    }
 >>
 >> The first is minimalist, the second easier to use.
 >
 >Minimalist and inherently non-portable if 'compose' is user code that 
must
 >understand and manipulate the path naming conventions.

No, I'm assuming 'compose' is supplied - it is the first of the "path 
operations" described in the document.

I've been writing some trial scripts.  The compose function (or functions) 
have to be specified very carefully or either portability or usefulness or 
both suffer.

 > There are a very
 >useful
 >set of file manipulation programs that can be written without any
 >manipulation
 >of the name strings and I believe the spec should strive to enable 
this.
 >BTW,
 >my example had a short cut with the "/usr/junk" built in.  Many programs
 >would
 >derive this initial directory string from user input or a root or current
 >directory context that will not require explicit strings.
 >
 >Given this I would add to the operations on Directories:
 >
 >* Given a dirpath, iteration yielding paths of all contained
 >files/directories
 >          ^^^^^^^                     ^^^^^
 >This, I think, should eliminate the need for the non-portable 
compose.  The
 >implementation might look like:
 >
 >
 >    //  get() and remove() on iterators
 >   for (path_itr i ("/usr/junk"); i != path_itr.end(); ++i)
 >    {
 >      if (!get <is_directory> (*i))
 >      {
 >        remove (*i);
 >      }
 >    }

I'll give that some more thought.

 >And you still need to add the following to the spec:
 >
 >* Given a path return a bool indicating if the path points to a directory

I've indicated that "is_directory" is one of the required attributes.

Thanks,

--Beman