Subject: Re: Extended Inode Information
To: None <tech-kern@NetBSD.ORG, mill0440@gold.tc.umn.edu>
From: Ty Sarna <tsarna@endicor.com>
List: tech-kern
Date: 12/03/1997 11:40:56
In article <Pine.SOL.3.96.971203081250.24086C-100000@gold.tc.umn.edu> you write:
> As others have pointed out the mac already has this concept, appearently
> the amiga does. Let me add OS/2 as anouther OS that has this concept. In
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.
Personally, I think extended information for HSM (which I'd love to see,
BTW!) and such should be system-private.
As far as attaching arbitrary user-specified data to files, I don't
think it's worth all the headaches of incompatibility unless it's going
to add *siginificant* functionality, like BeFS. If you just want to
store a few extra bits about a file, do like Workbench and store them in
another file. Just as good. Having the kernel manage the attributes is
only useful if it's going to be able to do useful stuff with them, like
query based on them (goodbye Unix find, hello SQL SELECT! :->).
So, I'm in favor of any proposal for altering the disk data structure
spec to allow kernel facilities that need to (HSM, AFS) to do so. Beyond
that... (gee, I feel like such an anti-FS-change radical! Me, a
proponent of @links!)
Oh, and as for ACL's. I'd love them. But, ACL's in UFS is only so
useful... unless they work over the network, they're not terribly
useful. I suggest anyone who really thinks they have the energy to do
major FS work instead implement a BSD-license freely-availible AFS clone
(either in features, design, or a true interoperable clone). That'd
solve a number of problems.