I would think even a UFS filesystem could emulate
that.
Where would you hide the creator attributes? Or, are you
uggesting a kludge workaround (e.g., change the "extension"
to something unique; build some middleware that consults
a user-maintained table of creator attributes; etc.)?
I haven't looked into this because my Macs all use HFS+, so I don't know how
Mac OS X emulates resource forks on a UFS filesystem (perhaps Zane or Doc do).
I don't believe that resource forks are supported on UFS filesystems. I
won't guarentee I'm remembering correctly though. ISTR this is why I went
with HFS+.
Besides we've already seen today how good my memory is with reguards to
creator attributes on Mac OS X. :^)
However, when storing Mac files on, say, a FAT volume,
a hidden folder is
made to hold the additional data in the resource fork. This includes
type/creator information.
Various solutions like this are used on various OS's. On VMS they're stored
in a MSAF$RESOURCES.DIR;1 directory. I forget how CAP and Netatalk do it on
Unix. All I know is when I finally move off of OpenVMS 7.3-2 and/or Mac OS
10.3.9, I'm going to have fun cleaning up all of that from my VMS server!
Upgrading either of those versions mean that my Mac will no longer be able
to use Appletalk to talk to my VMS server. :^(
Zane