[boost] Re: boost::filesystem file restrictions

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-15 18:02:49

"Victor A. Wagner, Jr." <vawjr_at_[hidden]> writes:

> At Friday 2003-08-15 14:03, you wrote:
>>"Victor A. Wagner, Jr." <vawjr_at_[hidden]> writes:
>> >>[deleted]
>>That changes the physical file(s) associated with certain paths, just
>>like deleting and creating files or creating symlinks.  It does not
>>change where those paths refer to in the filesystem.
>
> I'd be interested to know what you perceive to be "the filesystem".
> It's clearly an abstract concept, but everyone seems to have
> assumptions about what it looks like.  I suspect therein lies the
> current discussion.

It's a dynamic mapping between paths (addresses) and streams of bytes,
and a set of functions for operating on those streams.

> Common English words (absolute, relative, root) are being bandied
> about and applied to something we all see differently ("the
> filesystem").  I'm told there are systems out there that don't have
> hierarchical file systems (CP/M anyone? or maybe the AS-400 ummm,
> whatever) 

Or ancient MacOS, before HFS.

No problem.  Non-hierarchical systems are addressed by paths which are
a strict subset of the address space used for hierarchical systems.

> and apparently even systems without files (why else the
> committee's instance of calling them headers, header files?).

True, but irrelevant AFAICT.

> For those who seem to think that a "filesystem" is a hierarchical
> collection of "files" with a single root (what I'm told that *NIX
> does)

Not at all.  It does use a hierarchical addressing scheme, which has a
single root.  Lots of *NIX systems have multiple drives and other
physical roots under the covers.

> , I point out that the language we're all so fond of (C++)
> rejected this single hierarchy for it's inheritance of classes (and
> I'm glad, I really don't like deriving everything from object).

Also irrelevant AFAICT.  This isn't about inheritance, and when
addressing the filesystem you need to start somewhere.  Even in C++
all scoping starts with the global scope, ::.  Your classes all live
somewhere beneath that.

> Perhaps we all need to merge our views of what constitutes a
> filesystem or descriptions of portions of it become almost
> meaningless).

Yep.

> I suggest that perhaps because everyone has such strong connotive
> meanings attached to words like relative, absolute, and root that we
> not use them in such a discussion.

I guess you're coming to the same conclusion as the designers of the
filesystem library did.  I want to be able to use the traditional
terms though.

> I offer the word "anchor" to mean a named place in the "filesystem"

That sounds like what "path" means.

> also the concept of "current directory" which should probably be
> shortened to "current" paths then are either "from current" (no
> particular name for this) or "from some anchor" (anchored) whether a
> filesystem must have a single "super anchor" or multiple ones I
> leave open for discussion, tho I'm strongly in favor of multiple
> anchors.

You can pick any meaning you like for your new terminology.  I'm
concerned with being able to use the traditional terms in a coherent
and useful way.

> How all of this would be implemented should be irrelevant to the
> discussion (though whether it _can_ be implemented is surely a
> consideration)
>
> a thought on the determination of whether a path is anchored or not:
> define a character that cannot be used in a path _except_ to denote an
> anchor (I suggest ':' because it is "almost" an anchor marker in MS
> (a:, c:, etc.) and was even more so in AmigaDOS (df0:, volID13735:,
> sourcefiles: (AmigaDOS allows you to make up your own anchor names and
> place them arbitrarily in its filesystem)).

With all of the ways that you could interpret that idea on Windows
(what category is c:foo in?) I don't think I want to get involved
with a determination of anchored-ness.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com