Re: HFS+ feature request

Re: HFS+ feature request

[Dan Bethe]

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

	I understand that.  My request was basically just that we have an
option for that.  Basically, to have something like this:

# mount -t hfsplus -o rw,casesensitive /dev/sda1 /mnt/local/sda1

	And the default can be case insensitive-but-preserving, like MacOS and
the official specs state.  I just want the chance to be able to use it
as a "real" filesystem, sharing the maximum amount of space while I
still have to deal with the silliness of MacOS  :)  If I could format
/usr with HFS+, I'd give that a shot.
	If any of you have access to a MacOS 10 which installs its root with
HFS+, let's see how it behaves.  I have MacOS 10 "Server" 1.0 on my
powerbook, and its root fs is UFS BSD 4.4.

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

	Good idea.  Let's keep cooking on this!  It would be funny if
eventually HFS+ was the most compatible unix-based filesystem on all
Linux architectures  :)


=====
"Don't expect your own messiah; this neverworld which you desire is
only in your mind." -- http://www.dreamtheater.net/songb4.htm#IV5

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

Re: HFS+ feature request

[Brad Boyer]

Dan Bethe wrote:
> > 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.
>
> 	I understand that.  My request was basically just that we have an
> option for that.  Basically, to have something like this:
>
> # mount -t hfsplus -o rw,casesensitive /dev/sda1 /mnt/local/sda1
>
> 	And the default can be case insensitive-but-preserving, like MacOS and
> the official specs state.  I just want the chance to be able to use it
> as a "real" filesystem, sharing the maximum amount of space while I
> still have to deal with the silliness of MacOS  :)  If I could format
> /usr with HFS+, I'd give that a shot.
> 	If any of you have access to a MacOS 10 which installs its root with
> HFS+, let's see how it behaves.  I have MacOS 10 "Server" 1.0 on my
> powerbook, and its root fs is UFS BSD 4.4.

Well, there's a problem with ever writing anything to an HFS+ filesystem that
doesn't use exactly the same comparison routines as the official Apple method.
If you look at the linux code for HFS, it is paranoid about this as well.  The
problem is that the entire structure of the catalog is based on the ability
to sort filenames in a consistent order, and if you ever break that ordering,
it becomes impossible to search the catalog properly.  If we allowed case
sensitivity and wrote out a set of filenames which was illegal, than any
other HFS+ reader could lose files in very interesting ways.  I would absolutely
refuse to deliberately add code that would break the filesystem that badly.  At
the moment, I don't match Apple's string routines, but that's because I haven't
taken the time to fix it, and it's not quite as dangerous when reading.

I'm afraid I don't have any access to an OSX install, so I'll need help from
other people who do in order to support the extra UNIX style usage from there.

	Brad Boyer
	flar@pants.nu


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

Re: 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@pants.nu


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

Re: HFS+ feature request

[Kevin Kubarych]

Is it just me, or what? Seems to me hfs and hfs+ know about cases--when I
name a file ThisFile, it shows up in the finder with the caps, where does that
information get stored if not on the hfs/hfs+ disk? It's the MacOS that (for
whatever reason) doesn't differentiate between ThisFile and thisfile. Even when
you look at an hfs partition in linux, the cases are there, so it's not some
strange MacOS trick.

Still it seems that case sensitivity will only cause extreme disaster--that is
until everyone is on OS X (which doesn't even support long filenames yet,
whatever).

best, Kevin


On Fri, 25 Feb 2000, Benjamin Herrenschmidt wrote:

:
:On Fri, Feb 25, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
:
:>> 	I think HFS+ would be an excellent OS-coexistance compatibility
:>> filesystem.  It could work on Linux, MacOS 8/9/10, etc.  It supports
:>> multiuser permissions.  Yay.
:>
:>What about special device nodes (oh yes, we have devfs now :-)? Fifos?
:>Sockets?
:
:I think they can be implemented on HFS+ since MacOS X can be rooted on
:it. Note that HFS+ provides an extensible attribute b-tree so any kind of
:specific per-node infos can be added to the filsystem easily.
:
:


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

Re: HFS+ feature request

[Geert Uytterhoeven]

On Thu, 24 Feb 2000, Dan Bethe wrote:
> 	I think HFS+ would be an excellent OS-coexistance compatibility
> filesystem.  It could work on Linux, MacOS 8/9/10, etc.  It supports
> multiuser permissions.  Yay.

What about special device nodes (oh yes, we have devfs now :-)? Fifos?
Sockets?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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