Re: [9fans] files vs. directories

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

On Thursday, February 03, 2011 02:05:02 pm erik quanstrom wrote:
> > why do we keep distinction between files and directories? Does it provide
> > any extra value over model with unified file/directory?
> 
> yes.  the advantage is that it's easy to tell the difference
> between a file and a directory.

no comments ;-)


> and we have a lot of code
> that works with the current model.

That was my first objection, too; stuff like acme(1) could become strange: I 
can't imagine how to present mixed bytestream+subfiles/subdirectories in a 
reasonable way. Unless the user left the one of the forks empty, that is...
tar(1) would become confused beyond imagination.

How about 8c(1)? would it be too confusing to issue:
8c foo.c
if `foo.c' contained some C code, AND `foo.c/bar.h' contained some more C 
code?

rc(1)? How could `. foo.rc'  handle situation when also `foo.rc/bar.rc/baz.rc' 
exists?


The model seems somewhat sensible in regard to user-oriented documents, 
especially multi-part ones.

`mail/1' could hold body of an email message nr 1, and `mail/1/1' its first 
MIME part.

Perhaps /dev/sd0, /dev/sd0/p0, /dev/sd0/p0/p0 could make some sense in regard 
to drives, partitions etc.?



Perhaps my whole confusion stems from the fact I've never used any record-
oriented filesystem -- otherwise I'd understand pains related to it, as some of 
them would apply in case of my question.


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