At 1:23 PM -0800 6/6/02, Ethan Benson wrote:
On Thu, Jun 06, 2002 at 05:24:43AM -0700, Brad Boyer wrote:
quoted
but it can handle most standard UNIX features other than
hard links, which will show up as empty files. (Don't ask...)
in case anyone is curious the reason for this is because HFS+ has no
support whatsoever for hard links. Apple kludged around this by
making OSX create a MacOS alias pointing to an inode number (or
similar) this macos alias has a special magic id to it so OSX knows to
pretend its a hard link instead of a regular file like it really is.
MacOS aliases are of course stored entirly in the resource fork, which
this implementation has no support for, thus hard link -> empty file.
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.
(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.)
--
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/