My feeling from all these examples is that a path string is inherently specific to the system for which it was specified, and can't really be ported to anywhere else. Much like a string is usually inherently specific in its encoding to the system-specified encoding. However, the filesystem library can provide a portable way to manipulate this system specific path, much like the string library provides a portable way to manipulate the system-specific encoded string. In view of this, why try for a "portable path" at all?
This may have been covered already, but I would go further and assert that the very concept of a string path is non-portable. For example, in the Macintosh filesystem the beginning of a full path is the name of the volume. But two volumes may have the same name, leading to ambiguity. The only good way I've seen to counter it is a concept I saw implemented in the Be API and that I recently implemented on Mac. Basically you create a VolumeRoster that enumerates the mounted volumes and their attributes, and build your path out from there until you have an Entry, which is a theoretical location that may or may not point to a Node, an actual filesystem object. Paths can be used as constructor arguments for Entry's for systems on which paths are unique, but to stay portable you obtain directories sequentially until you have the Entry you desire.
This of course presumes a hierarchical file system, another portability topic that has been discussed. In addition, taking Macs into account, something my code does is get named streams on files, correlating to forks. A file by itself can be streamed into and out of, and the implementation platform is responsible for supplying a default fork for this (Mac defaults to the data fork). But you can also query the file for (and create) other forks and get their streams.
Should we (do we?) have some spreadsheet enumerating various filesystem features, quirks, and limitations for whatever systems we can find, and using that as a reference regarding how to organize features like paths, file references, forks, or whatever else? It might help us to back out of the code and re-examine the problem domain regardless of the current state of Boost.
-- Brian Gray
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
