Glen Knowles <[EMAIL PROTECTED]> writes: >>From: David Abrahams [mailto:[EMAIL PROTECTED] >>>> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
