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

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-02-23 12:58:08

> the names of the attributes are taken just from the identifiers of the
> corresponding posix-flags and member in stat. i think the best
> solution would be to list all available attributes from several
> platforms (win, mac, ...) and then try to find better unique names and
> specify which of them must be supported and which are implementation
> defined.

I'm in full agreement that we should list the attributes and unify the interface
as much as possible.  However, I believe the name and directory versus file
attributes must be guaranteed.  All the rest are option.

In Beman's proposal he states:

  The world is divided into files and directories.
  ....
  path The path to a file or directory, including the name....
  filepath The path to a file, including the filename....
  dirpath The path to a directory, including the dirname...

Some of the operations in the specification apply only to 'dirpaths' while
others apply only 'filepaths'.  If there is no guaranteed interface that allows
me to interrogate a 'path' to figure out if it is a dirpath or filepath, I am
unhappy.  Looking at it again I think there is a more fundamental issue, because
there is no iterator over a 'dirpath' that returns 'paths'.

So put another way, how does the proposal support the equivalent of this perl
code?

   # delete the files from a given directory, but not the directories...
   opendir(MYDIR, "/usr/junk"); #open handle to a directory path /usr/junk
   foreach($name = readdir(MYDIR)) #iterator in perl gives all files and
directories
   {
        if (-f $name) { #test if the 'path' is a file or directory
         unlink($name);  #delete the file
      }
   }

Jeff