Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-21 10:34:19


At 02:49 PM 8/19/2003, Brian Gray wrote:

>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.

The Mac example you bring up was brought up during original design. The
decision was not to add specific class path features. See below for part of
the rationale for that decision.

>
>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.

I started to make such a table, and in doing research for it found out
that the more important legacy operating systems (IBM OS/390, OS/z, etc.)
had added POSIX file subsystems. Plus new operating systems seemed to be
gravitating toward POSIX compatibility as far as file systems went. That
lessened the need, IMO, to worry about file system other than POSIX,
Windows, and ISO-9660 variants.

If someone else would like to do more research, it would be welcome, but I
don't think it is a critical need right now. Dealing with wide-character
names is much higher on my priority list, for example.

Thanks,

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk