[9fans] files vs. directories

[dexen deVries <dexen.devries@gmail.com>]

As this list seems to be open to discussion of strange OS-related ideas, here 
goes my question:

why do we keep distinction between files and directories? Does it provide any 
extra value over model with unified file/directory?

A possible consideration for representation of unified files/directories is a 
three-part file: name (& other meta), byte-stream (==content), ordered list of 
subfiles (== subfiles/subdirectories). In a way, that'd be somewhat similar to 
files with two forks you can see on some OSes. Or, to put it the other way 
around, it's like a directory with extra section for one unnamed byte stream.

Path sematnics stays exactly the same:
read(open("/foo/bar")) returns byte stream related to entry `bar' in (for lack 
of any better word) object  `/foo'.

read(open("/foo")) returns byte stream under entry `foo' in the root object.

readdir("/foo") returns `bar' (and possibly others) -- entries in hierarchical 
section of object `/foo'.

The sourece of the idea is a (www) CMS I'm working on which doesn't make such 
distinction, and it somehow makes some sense -- at least as served over HTTP & 
addressed via URIs.


-- 
dexen deVries

[[[↓][→]]]

> how does a C compiler get to be that big? what is all that code doing?

iterators, string objects, and a full set of C macros that ensure
boundary conditions and improve interfaces.

ron minnich, in response to Charles Forsyth

http://9fans.net/archive/2011/02/90