Extensions to HFS filesystem
Paul H. Hargrove (hargrove@sccm.stanford.edu)
Sat, 27 Apr 1996 20:36:50 -0700
As author of the Macintosh HFS filesystem (for info check out
http://www-sccm.stanford.edu/~hargrove/HFS/) my eventual goal is to
have a filesystem that is as nearly like a native Linux filesystem as
possible. For FAT this has been done with UMSDOS which stores all the
info that can't be mapped directly to FAT in a special file.
While that solution seems to work very well it is prone to all
sorts of things getting out of sync when MSDOS is run on the filesystem.
I'd like to limit similar problems with HFS by using the little bit of
extensibility that is bulit into HFS. In particular I'm refering to
using the Creator and Type fields of an HFS directory entry. For
thoes not familliar with the Mac these fields are associated with each
file (but not directory) on an HFS disk and are each 4-characters long
with values registered with Apple to prevent conflicts. Apple reserves
codes made of all lowercase letters.
Since Creator and Type are only applicable to files they are
not a suitable way to store permissions (besides I don't feel like
filling in the forms to register 20480 different Types to catch the
octal representations of all the possible modes). However they would
provide a way to encode the S_IFMT part of the mode bits, with values
such as "LINK" for symbolic links and "CHAR" for character devices.
The actual symbolic link or device numbers would end up as the data in
the file, which to a Mac would be a normal file.
I suggest "FHFS" (Free HFS, since I hope my work will later
be ported to other free Unixes) as Creator and "LINK", "BLCK", "CHAR",
"FIFO" and "SOCK" for Types. One additional type (perhaps "PERM"?)
would eventually be used for a file to store owner, group, permission
(and atime?) info but would be one per filesystem rather than one per
directory and stored by CNID (the HFS equivalent of an inode number)
rather than name so it would stay current when files and directories
are moved/renamed under MacOS.
The question of how to handle hard links remains open. I
don't like what UMSDOS does, but can't think of a good alternative.
So I'd like your opinions on these ideas. They are not going
to be implemented very soon, but I'd like to get the discussion going
now so the issues are settled when I am ready to implement it.
--
Paul H. Hargrove All material not otherwise attributed
hargrove@sccm.stanford.edu is the opinion of the author or a typo.