Re: [boost] Re: boost::filesystem file restrictions

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
>www.boost-consulting.com

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