Re: HFS+ support (read-only)

On Thu, Jun 06, 2002 at 03:50:31PM -0700, Timothy A. Seufert wrote:

I thought there was also a special file (completely hidden from
userland in X) which tracks all the hard links in the FS.  I'm pretty
sure something like that is necessary to truly implement hard link
semantics.  Consider what happens when a file with hardlinks gets
unlink()ed -- then all its hardlinks point at nothing.  The OS needs
a database of all files that are hardlinked, with full reverse
mappings, so that whenever a file with hardlinks is unlinked it has
enough information to replace one of the hardlinks with the real file.

i don't know about that, maybe.  to be honest it would not surprise me
if apple just let that break.

(For efficiency I'd want a flag bit in the metadata of each file to
indicate that it has been hardlinked, to avoid searching the table
when deleting files that have no hardlinks.  For even more
efficiency, a direct pointer to the table entry.)

you cannot use the word efficient to describe this puke inducing
kludge.  the efficient way is to design the filesystem properly to
begin with, which apple did not do with HFS+.

--
Ethan Benson
http://www.alaska.net/~erbenson/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 11:25 PM -0800 6/6/02, Ethan Benson wrote:

On Thu, Jun 06, 2002 at 03:50:31PM -0700, Timothy A. Seufert wrote:

quoted

 The OS needs
 a database of all files that are hardlinked, with full reverse
 mappings, so that whenever a file with hardlinks is unlinked it has
 enough information to replace one of the hardlinks with the real file.

i don't know about that, maybe.  to be honest it would not surprise me
if apple just let that break.

Oh, come on.  :)  I just tested it, they didn't let it break.

quoted

 (For efficiency I'd want a flag bit in the metadata of each file to
 indicate that it has been hardlinked, to avoid searching the table
 when deleting files that have no hardlinks.  For even more
 efficiency, a direct pointer to the table entry.)

you cannot use the word efficient to describe this puke inducing
kludge.  the efficient way is to design the filesystem properly to
begin with, which apple did not do with HFS+.

The kludge part is trying to retrofit features like hardlinks into a
FS which wasn't designed to naturally support them (as classic UNIX
inode FS designs do).  Aside from that I see nothing wrong with the
basic design of HFS+.

--
Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/