Re: [boost] Filesystem portable path rationale and use-cases

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