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 <[EMAIL PROTECTED]> 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? >
