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

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-02-23 16:55:21

> 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.".

>    //  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. 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);
      }
    }

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

Jeff