In article <199712031944.UAA16559@kurt.tools.de> you write:
> > Actually, the Amiga does the exact opposite. A file may have an
> > associated file with the extension ".info", which the Workbench
> > (desktop) application stores icon image, icon position, associated app,
> > etc, stuff in. It's done at the application level, not at the kernel

> Note that ISO9660 supports something similar, namely so-called 'associated
> files'.  These have the same name as the file they are associated with, but
> some additional attribute bit.  Other than that, there is no semantic implied
> with these associated files.

AGH! No, this is not at all similar.  You said "ISO9660 supports ...". 
That's right.  It's special magic in the filesystem.  There is *no*
special support in the Amiga filesystem.  There are two files.  Period. 
That's all they are, two plain, ordinary files.  One has an extension
that, *to a particular application* marks it as being related to the
other.  That's the only relationship.  file and file.info are no more
related as far as the OS is concerned than file.c and file.o are, or
file and file.gz.  It works on any filesystem. 

Regarding someone's comment about wether these attributes should have
their own permissions, timestamps, etc...  great... by the time you get
done implementing all these cool features, you've essentially duplicated
the functionality of files. Except now you have two APIs for
manipulating similar objects, twice as many system utilities (or adding
new flags to all of them), etc. And you haven't added anything that
can't be done by just using more plain files. It's sort of analogous to
RISC vs CISC, and I guess I'm a RISC proponent. Plus, now you have
headaches when you want to back files up, or sharing them over the
network, etc.

One suggested use for these extended atrributes was to store things like
the compiled bytecode for a perl script.  Why, for heaven's sake? To
ensure that Perl is a huge pain in the ass to port to other systems? To
make sure that even on systems with this special functionality that the
functionality is only availible on some filesystems mounted on a system?
You can do exactly the same thing with a second file.  Python does
exactly that.  If you "import module", it looks for module.py and
module.pyc.  If the .pyc (bytecode) doesn't exists or is older, or has
abad magic, the .py (source) version is read and compiled, and if
possible the bytecode will be written to module.pyc, to save time the
next time it's needed.  It's simple, reliable, and portable.  Works on
Unix, Amiga, Mac, DOS, Windows, OS/2, VMS, and who knows what all else. 
Works on any filesystem, and over a network, too. 

>From my point of view, it looks like people are inventing excuses to
implement new functionality without any real reason for it, other than
it sounds cool.

Regarding the HSM thing, I'm beginning to think the single bit
implementation is the right way to do that, too. Keep the HSM metadata
in a separate file(s) or database. That way, it can be easily backed up.
Yes, it causes another reference in some cases, but you can always put
it on another spindle, if you want. It also means that you can add or
change the format of the metadata without having to change all the
system utilities. You can add new methods of indexing it, without having
to hack the kernel, etc. The amount of kernel support needed to
implement this would be quite small, really. The kernel just needs to
consult a daemon on open of files with that bit set. Everything else can
happen in userland.