Re: [boost] Filesystem rooted paths make_absolute proposal

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-19 19:26:28

At 04:23 PM 9/19/2002, Thomas Witt wrote:

 >I propose the following changes to the filesystem path interface in
 >order to solve the problem of rooted/absolute paths.

Before getting into details, overall I think I like your idea of treating 
the concept of a "root" separately, with some operations that operate on 
"roots". This separation from the "root directory" concept is helpful.

Be warned, however, that a number of past ideas had to be abandoned after a 
lot of work went into them.  This stuff is messy because of the portability 
issues.

I'm going to reorder some of your messages to start for ease of discussion. 

 >I'd like to introduce the notion of a path 'root' and of an 'absolute
 >path'.
 >
 >Root:
 >A filessystem can have multiple roots(e.g. C:;D:) each filesystem has at
 >least
 >one root. A path can be rooted. That means it belongs to the hierarchie 
of
 >its root.

Also, a rooted path can be either absolute or relative, as can be a 
non-rooted path.

 >    class path
 >    {
 >      ...
 >    /*
 >     * Returns an empty root for
 >     * non rooted pathes.
 >     * Otherwise a non empty root
 >     */
 >    Root const root() const;
 >      ...
 >    };
 >
 >

Good, but see the comment below about the return value.

We also need to be very sure of each element in the path model for the 
following cases (assume Windows). Assume leading "/" gets added to the 
grammar as "root directory".

    p.generic_path() has_root() has_root_dir() Elements
    ---------------- ---------- -------------- --------
    "c:"             true       false          c:
    "/"              false      true           /
*  "c:/"            true       true           c:,/
    "foo"            false      false          foo
    "/foo"           false      true           /,foo
    "c:foo"          true       false          c:,foo
*  "c:/foo"         true       true           c:,/,foo
** "//share"        true       true           //share
*  "//share/"       true       true           //share,/
*  "//share/foo"    true       true           //share,/,foo

Cases marked (*) represent a change from the current specs in that they 
separate the concept of "root" from "root directory".

Note that the definition of is_absolute() is has_root() && has_root_dir(), 
but this may be too complicated. Maybe better to replace has_root_dir() 
above with is_absolute.

I'm not 100% sure (**) is a valid case, but that isn't important.

 >     * Root that refer to the same filesystem
 >     * hierarchy are guaranteed to compare equal.

 >The path iterator no longer references the root element of the
 >path. I.e. iterating over a path means iterating over path elements
 >as defined in the grammar. From my experience that would greatly
 >simplify path iteratoin.

Sometimes users will want iteration to include the root, sometimes they 
won't. Ditto root_directory(). Rather than exclude the root and/or 
root_directory from iteration, I'd say provide bool functions to say if 
they are present (has_root(), has_root_directory()), and extraction 
functions.

The case of "/" on POSIX, which is both, would need to be handled 
carefully.  Because of that, I'd like to work the above table out again, 
assuming "/" wasn't added to the portable grammar, and see if that 
eliminated the need for the "root directory" concept and functions.

 >Roots are modelled by a newly introduced root type that
 >provides the following public interface. An access method
 >is added to path to retrieve the root. Whether Root has to be default
 >constructable needs further investigation.
 >
 >namespace boost {
 >  namespace filesystem {
 >
 >    class Root
 >    {
 >    public:
 >      bool empty() const;
 >    };
 >
 >    bool operator==(Root const&, Root const&);
 >    bool operator!=(Root const&, Root const&);
 >    bool operator<(Root const&, Root const&);

Doesn't work. For many file systems there is not way to tell if two roots 
are equal, because of aliases.

It really seems to me that Root reduces down to a std::string, just like 
any other element in a path.

 >Absolut Path:
 >An absolute path describes a fixed named location in a filesystem
 >hierarchy. Note that the location is fixed with respect to the name
 >not the referenced entity. Its counterpart is the relative path. An 
absolute
 >
 >path must have a non-empty root. A relative path does not have to be 
rooted
 >but it can be rooted. Forinstance on Windows C:xy.txt is a relative 
rooted
 >path.

 >To support the notion of relative/absolute paths the following methods 
are
 >added/modofied. Whether these should be members/nonmembers needs further
 >investigation

Here is the rule I have been using to determine the member/nonmember 
questions: If the function operates on a path purely at the lexical level, 
without calls to the operating system, then it is a path member 
function.  If the function operates on the underlying filesystem (by 
calling the operating system), then it is a non-member function.

 >
 >namespace boost {
 >  namespace filesystem {
 >
 >    class path
 >    {
 >      ...
 >    /*
 >     * Returns true if path is absolute
 >     */
 >    bool is_absolute() const;

Why is_absolute() rather than is_relative()? Which would be clearer in the 
corner cases like Windows "c:foo", "/foo"?

 >    /*
 >     * Precondition p.root().empty()
 >     */
 >    path& <<=(path const& p);
 >
 >    /*
 >     * Precondition p.root().empty()
 >     */
 >    path const operator<<(path const& p)

With composition functions like those below, the <<= and << preconditions 
can probably be tightened. You were smart to realize that:-)

 >      ...
 >    };
 >
 >    /*
 >     * Returns an absolute path by either
 >     * prepending the current working directory
 >     * of the application, or by inserting the root
 >     * specific working directory for rooted paths.
 >     * Does nothing if p is absolute.
 >     */
 >    path const absolute(path const& p);
 >
 >    // We may want to provide the following
 >    // convenience method
 >    /*
 >     * Merges p1 and p2.
 >     *
 >     * Precondition ((p1.root() == p2.root())
 >                     || p2.root().empty()
 >                     || p1.root().empty) )
 >                    if both are absolute one must be a sub path of the
 >other.
 >     */
 >    path const merge(path const& p1, path const& p2);

I'd rather settle the other questions first, then look at the additional 
functions.

 >Comments ?

Notice that none of the above makes any substantial change to the current 
library.  It is all additional functionality to make dealing with roots and 
relative/absolute issues much easier.

Basically, we would like to reduce the cases where the users has to paw 
around with the path iterators to really unusual situations. And increase 
the number of operations that can be done portably by the user.

That's the key rationale for adding path::root() and the query 
functions.  There is no portable way for the user to write the equivalent 
functions.

Thanks for all the ideas,

--Beman