"Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes: > At Friday 2003-08-15 14:03, you wrote: >>"Victor A. Wagner, Jr." <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost