Re: Extensions to HFS filesystem

Paul H. Hargrove (hargrove@sccm.stanford.edu)
Mon, 29 Apr 1996 18:27:43 -0700 (PDT)

Albert Cahalan <albert@ccs.neu.edu> wrote:
> > 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 agree that this is wastefull (under HFS the worstcase is
that each device file uses 1/32767 of the disk and best case is
1/65635), however a solution that separates the information from the
file is prone to corruption by users of the disk under its native OS.
I have the advantage under HFS of a fixed inode number which FAT
lacks, so I could place the information in a central database, but
then if a user tries to copy a device file using MacOS the result is
not what was expected. Apple wants to see MkLinux work on an HFS
filesystem so perhaps I could talk them into allocating some of the
reserved bytes in a directory entry, but I'm not sure the Finder would
copy those bytes. (or perhaps I could each monkeys to fly :-) )

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

I'll see if I can get Apple to disclose some info. As stated
above they do actually have an interest in seeing this work completed.
The thing is that they have aliases so have no need to add symlinks
and device files, unix-domain sockets and fifos are all pretty
unix-specific. It maybe possible to map unix-style permissions onto
the AppleShare permission system, but I don't know where that info is
even stored.

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

I agree with you on this. I think that initially I'll do
exactly as you suggest and have a mount option to decide if link()
produces a symlink or fails. Are there any GOOD arguments against
this?
In the end the goal is to be able to run a Linux system on an
HFS filesystem with no other filesystems available. I imagine that
there utilities out there that depend on hardlinks doing "the right
thing" so that it doesn't matter which of two files you delete. These
are going to be a problem.
----
Paul H. Hargrove All material not otherwise attributed
hargrove@sccm.stanford.edu is the opinion of the author or a typo.