[boost] Re: boost::filesystem file restrictions

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-15 10:03:34

Glen Knowles <gknowles_at_[hidden]> writes:

>>From: David Abrahams [mailto:dave_at_[hidden]]
>>>>     portable_path("/foo/bar") <- throws on Windows
>>>
>>> Not sure why this would throw, what is the purpose of portable_path?
>>> "/foo/bar" is perfectly reasonable on Windows.
>>
>>It's perfectly reasonable but it doesn't have a portable meaning.  It
>>is a relative path w.r.t. the drive of the current directory.
>
> Almost all paths are relative w.r.t. something, the current users
> filesystem mapping, the computer, the network. 

I find that somewhat compelling... but in the end it doesn't hold up.

> I don't see how
> leaving out the drive makes it less portable then leaving out the
> computer name.

It's less portable because how it is to be interpreted *with respect
to the filesystem* can change dynamically.  Remember the name of this
library, "filesystem"? ;->

Filesystems belong to computers.  A computer's filesystem is accessed
via an infinite tree of names (**).  How those names which correspond
actual storage are mapped can be modified dynamically in any number of
ways: you can have symbolic and hard links, mount drives, remote
computers can come online or go away, non-storage devices can be
mounted at locations in the tree etc.  The one constant is the
structure of the tree of names which allows us to access a virtual
location in the filesystem (as opposed to physical).

A path is a set of instructions for traversing the name tree.  By any
reasonable definition, an absolute path identifies a single virtual
location in a filesystem's name tree, not one that can change based on
the process state.  A path on windows that starts with '/' is a set
of instructions which begins: "go to the root of the current
directory path".  That's clearly dependent on the process state.

(**) You may want to say that the tree is multi-rooted, but I don't really
see the point, since you can make it single-rooted by adding a common
root node.  Anyway, whether it's single-or multi-rooted is irrelevant
to the question of absoluteness.

>>>>This is also a way we could solve the whole problem of absolute paths.
>>>>It's clear that "/foo" isn't an absolute native windows path.
>>>
>>> This is not at all clear. I have and will contain to argue that
>>> "/foo" is an absolute windows path, since it does not respect the
>>> current directory.
>>
>>If you define anything that is not relative to the current directory
>>as absolute, maybe you can say that.  It seems perverse to say that a
>>path which is _relative_ to something other than the machine in use
>>is absolute, though.
>>
>>> Also very important to me, this goes well with the URI definitions
>>> of absolute and relative

I disagree with that, for reasons expounded below.

>>I'm pretty sure this is an illusion!  URIs don't have a notion of
>>"current drive" do they?
>
> URIs are a multirooted system that have the semantics I'm advocating for
> file paths. To make an example, if you are looking at
> "http://localhost/somedir/index.html" it might have an absolute (as defined
> by the RFCs) href of "/foo/bar" that takes you to "http://localhost/foo/bar"
> and another relative (again, as defined by the RFCs) href of "foo/bar" that
> takes you to "http://localhost/somedir/foo/bar". This is because paths,
> relative or absolute, are with respect to the authority (localhost in this
> case).

Yes, an absolute URI identifies a single location in the virtual name
tree.  The only way to make this like a current-drive-relative path is
to consider processes which are moved, *during execution*, across a
network of computers.  I've never heard of systems which do that that,
but even if they exist I don't think they make an appropriate model on
which to define the notion of "absolute path" in a filesystem library.

> If you can give me an example of a multirooted system that refers to
> paths that are absolute with respect to the current directory as
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What does that mean?
And what does it mean for a multirooted system to "refer to a path as
relative?"  Do you mean in the official platform specification, or
something else?

> relative I'd be interested, my multirooted experience is limited to
> CP/M, DOS, AmigaOS, OS/2, Windows, and URLs. I don't have any big
> system experience with them.
>
>>> and it would be nice if the path class could support full URIs.
>>
>>Are we talking about native or "portable" representation now?
>>There's no reason they couldn't support full URIs in their portable
>>representation.  It's just a question of how that gets mapped onto
>>the native filesystem.
>
> What I'm thinking of may not be in the scope of the filesystem
> library. I'd like a path class that could directly manipulate URLs;
> authoritys, fragments, options and all. Direct use of "file:/.."
> URLs would be good too.

Great idea, IMO.  But yeah, I don't think it's in the scope of the
filesystem library.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com