Subject: Re: Large inodes for ffs
To: Erik E. Fair <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 03/23/1999 13:32:16
On Tue, 23 Mar 1999, Erik E. Fair wrote:
> Is this sufficiently general to subsume the MacOS HFS "resource fork"?
Probably, but there's a lot between here & there. If the fs supported it,
the vnextops mechanism could be used to support resource fork calls (well
the file-specific ones). Also, an overlay fs could use the opaque data to
store enough info to hack together a resource fork.
We decided that an inode could contain at most one type of opaque
(application specific) data. To do anything else would be sticking a file
system in a file, and that's messy. :-)
Also, the opaque data starts with a magic number, so that different
applications (users of the data) can tell if a node has their data or not.
Also, the magic numbers are reserved both normal and byte-swapped, so that
applications can tell if the opaque data is theirs from an opposite-endian