HFS+ support (read-only)

HFS+ support (read-only)

[Brad Boyer]

I've just uploaded a new release of my hfsplus module. If anyone
would like to try it out, or critique my code, you can find it
on Sourceforge (I am currently using 2.4.18-pre7 as a base):

http://www.sourceforge.net/projects/linux-hfsplus/

This is still read-only, and no resource forks in any format,
but it can handle most standard UNIX features other than
hard links, which will show up as empty files. (Don't ask...)

I haven't had any stability problems, but the performance is
somewhat slow on a disk with a large number of files.

I appreciate any feedback or suggestions.

	Brad Boyer
	flar@allandria.com


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

Re: HFS+ support (read-only)

[Ethan Benson]

On Thu, Jun 06, 2002 at 05:24:43AM -0700, Brad Boyer wrote:
> 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.

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

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

Re: HFS+ support (read-only)

[Timothy A. Seufert]

At 1:23 PM -0800 6/6/02, Ethan Benson wrote:
>On Thu, Jun 06, 2002 at 05:24:43AM -0700, Brad Boyer wrote:
>>  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/

Re: HFS+ support (read-only)

[Ethan Benson]

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/

Re: HFS+ support (read-only)

[Timothy A. Seufert]

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

>>  (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/