Re: Extensions to HFS filesystem

Albert Cahalan (albert@ccs.neu.edu)
Mon, 29 Apr 1996 16:12:22 -0400 (EDT)


> 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 hate the way umsdos does this. Each device file, link, fifo,
and socket, uses a disk cluster. That's often 16 kB per device file,
and /dev has quite a few.

> 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.

See what System 8 is doing first. Maybe some useful things will be
added. It would be good to avoid the umsdos/vfat duplication
caused when MS added a second timestamp and long filenames.

> 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.

If you can't do it right, DON'T DO IT, PLEASE!!!

The umsdos filesystem is severely broken. There are very few times
that a symbolic link is not equivalent to a hard link. You don't
even need hard links on the root partition. You could have the system
call return an error or make a symbolic link (a mount option?), but
please don't try to pretend that hard links exist when they don't.