From: Brian Gray (briangray_at_[hidden])
Date: 2003-08-19 13:49:35
On Tuesday, August 19, 2003, at 12:35 AM, Yitzhak Sapir wrote:
> 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