HFS+ feature request

[Brad Boyer]

Brian Downing wrote:
> The filesystem isn't case-sensitive.  This doesn't bug me _that_ much, I
> suppose, but some system calls feel a little broken:
>
> % touch README
> % touch test
> % mv test readme
> mv: rename test to readme: file exists
> % mv test README
> % ls
> README
>
> The mv error is from the rename(2) system call returning -1.  Fine,
> except that in the documentation it states that if the "to" argument
> exists, it is removed first.  In a case-insensitive filesystem, I expect
> "README" to be replaced with "readme".

The official format of HFS+ does specify that the strings are compared
in a case insensitive way.  In fact, it goes further and specifies a
bunch of details about actual Unicode sequences and I really don't want
to break all of that.

> Symlinks show up as a file in MacOS.  I was hoping they would be able
> to do them as aliases, but I suppose they can't.
>
> Aliases show up a zero-length files in Unix, because all of the alias'
> stuff is in the resource fork, which I haven't been able to find a way
> to get at with Unix calls.
>
> Hard links (this is scary) make _all_ linked files show up as aliases
> to diskname:FileNodeDataXXXXX in the MacOS, where XXXXX is a number
> (inode number, or the HFS+ equivalent?).  The aliases are unresolvable,
> and the FileNodeData file does not exist.

If you can give me an image of an HFS+ filesystem with some of this UNIX style
stuff, I can enable that stuff in the linux driver as well.  The official
spec doesn't say much about the permissions, ownership, devices, etc.  It
just says that they will be supported, and reserves a block for UNIX style
info like device numbers and uid/gid.  I figured I'd ignore that stuff until
I could get more info about the way OSX would handle it.

Just in case anyone is wondering, I have some preliminary code that a few
other people are helping me with, but I'm swamped at work and haven't had
much time.  Volunteers are much appreciated.

	Brad Boyer
	flar at pants.nu


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