Boost logo

Boost :

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2003-08-15 17:33:58

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.
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) and apparently even systems
without files (why else the committee's instance of calling them headers,
header files?).

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), 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). Perhaps we all need to merge our
views of what constitutes a filesystem or descriptions of portions of it
become almost meaningless).

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 offer the word "anchor" to mean a named place in the "filesystem"
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.

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

>Dave Abrahams
>Boost Consulting

Victor A. Wagner Jr.
The five most dangerous words in the English language:
               "There oughta be a law"

Boost list run by bdawes at, gregod at, cpdaniel at, john at