[boost] Re: [filesystem] Operations predicates

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-05-03 20:03:40

"Rob Stewart" <stewart_at_[hidden]> wrote in message 
news:200505031500.j43F05Z2022575_at_weezy.balstatdev.susq.com...
> 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.

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