"Rob Stewart" <stewart@sig.com> wrote in message news:200505031500.j43F05Z2022575@weezy.balstatdev.susq.com...
From: Beman Dawes <bdawes@acm.org>
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.
basic_filesystem_error<>.
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.)
That seems more confusing than just having two separate functions.
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.
That seems clearer. Thanks!
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.
For "read only" specifically, we had a long discussion in the early days of the library, and came to the conclusion that it just isn't portable. On POSIX, the concept of "read only" just isn't there in any usable form. In general, the thought was to add properties queries, which might or might not be available on any given operating system, and ould be queried for availability. I elected to not include them as part of Boost.Filesystem initially because I wanted to focus on core functionality. Nothing has been done about properties since then AFAIK. Thanks for the feedback, --Beman