> 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
> level, and plain single-stream files are used. There is no special
> kernel magic to support it. That also means that you can back an amiga
> filesystem up with a 100% vanilla port of tar, and not lose them. It
> means the Amiga can NFS mount a directory and you can have icons on the
> files there, without extensions to the NFS protocol or other special
> magic. I think this is far preferable.

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.

As an aside, since this attribute seems to be ignored by most 9660
implementations, and the associated files are required to be before the
non-associated file with the same name in a directory, you tend to get only
access to the associated file.  E.g. with SunOS you get a warning that the
associated attribute isn't supported, if you try to access a file that has
an associated file, but it will give you access only to the associated, not
the other one :-).

In our implementation, associated files get a '=' prepended to their
filename.  Note that '=' is not allowed in a filename on 9660 volumes.
I seem to remember that I changed it to this when I got a description that
some NFS implementation for the MAC did it this way.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800