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
