Re: [boost] [filesystem] Operations predicates

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-05-03 10:00:05

From: Beman Dawes <bdawes_at_[hidden]>
> 
> I've completed an analysis of expectations for the exists() and is_xxx() 
> family of functions, and the previously suggested status() and 
> symlink_status() functions.
> 
> See http://www.esva.net/~beman/filesystem_operations_predicates.htm

I like that you specify the behavior of the is_xxx functions in
terms of status().  That reduces the complexity of specifying the
is_xxx functions.

There's no mention of what exception is thrown for each of the
is_xxx functions.

I don't like the status()/symlink_status() split.  How about
overloading like this:

   struct follow_symlink_t { };
   extern const follow_symlink_t follow_symlink;

   status_flags status(path const &);
   status_flags status(path const &, follow_symlink_t);

Client code will then always call status(), but will sometimes
add follow_symlink.  I think it reads better.  (An OS that
doesn't support symlinks can simply make the latter call the
former.)

The Effects sections are a little awkward to read because of all
of the "Otherwise, if"s.  Perhaps something like this would work:

   Effects: Queries the operating system to determine the
   attributes of path p. If p is a symbolic link, the link is
   resolved (that is, deep semantics). If the attributes indicate
   that p is a directory (see expectations), it returns
   directory_flag. If the attributes indicate that p is a file,
   it returns file_flag. If the query results in an error
   indicating that p could not be found footnote, it returns
   not_found_flag. If the query results in any other error, it
   returns error_flag.

What about the other attributes that one can get from many
(most?) OSes?  Shouldn't status() report on read only, for
example?  The good news is that the status() I/F is extensible.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;