Unix already has this, and their called extended attributes, and I hate them
with a burning passion.  Rsync, cp, any tool that manipulates files (tar for
example) has to be able to capture this data, and just reading the file
won't do it anymore.
Oh and to make things more "fun" FreeBSD, Linux and Mac OS X at least have
different ways of dealing with them, and max size limits etc.

Where are people picturing the great utility of them?  I've found it to be
the worst thing invented since symlinks (except maybe relative symlinks that
use environment variables to complete part of the path... Makes everything
way more complex than it needs to be)

Note that Mac OS X (and GNUStep?) already does treat certain directories as
a single unit, and the structure is what makes up a framework or a .app
application, or even .pkg files.  It is clear that there are other ways to
achieve this sort of abstraction without changing file/directory semantics
that we already have any more than people already have done.

Having personally written parts an archiver that captures these adorable and
non-standardized bits of information  somewhat well hidden in files, and
having used the less than ideal APIs to access them, well lets just say I'd
rather throw out my computer and play Nintendo Wii for the rest of my
life...

My 2 cents...  It's probably worth less than that though

On 8/16/07, jsnx <jason.dusek@gmail.com> wrote:
>
> I'm not sure if this is the right place to post this, but it seems
> like a good fit. What better forum for deep thought on the meaning of
> files and directories than the Plan 9 news group?
>
> There would be great utility in merging files and directories into a
> composite content/container object that respond 'read' and 'write' for
> file ops and 'list', 'add', 'delete' for directory ops. For example, a
> disk drive could respond to 'read' with a bunch of stuff on the disk,
> and respond to 'list' with a listing of it's hardware settings, which
> could be set with a 'write'. Merged file/directories also make a lot
> of sense when you think about languages with hierarchical modules --
> instead of having naming conventions to find a sub-module, you just
> look it up and read it. Similarly, hierarchical documents map straight
> on to the mixed file/folder -- you put the intro in the head and its
> components under the head.
>
> I'm sure this idea has come up in the past; many of my ideas are like
> that. The 'everything is a file' model is proverbial, but it was not
> so once upon a time. I'm sure the 'everything is a directory' model
> had its proponents in days gone by, just as functional languages did
> (and will again!). In fact, 'everything is a directory' is the man
> behind the curtain in LDAP.
>
> In the considered opinion of the list, is "everything is a directory"
> a big mess, a resource wasting fantasy, an idea whose time has come?
>