linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Brad Boyer <flar@pants.nu>
To: dan_bethe@yahoo.com (Dan Bethe)
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: HFS+ feature request
Date: Sun, 5 Mar 2000 16:32:17 -0800 (PST)	[thread overview]
Message-ID: <200003060032.TAA10926@marcus.pants.nu> (raw)
In-Reply-To: <20000303203225.3481.qmail@web1001.mail.yahoo.com> from "Dan Bethe" at Mar 03, 2000 12:32:25 PM


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/

  reply	other threads:[~2000-03-06  0:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-03 20:32 HFS+ feature request Dan Bethe
2000-03-06  0:32 ` Brad Boyer [this message]
     [not found] <200002251949.NAA09042@wolfram.com>
2000-02-28 21:47 ` Brad Boyer
     [not found] <20000225113608.001404@mailhost.mipsys.com>
2000-02-25 17:16 ` Kevin Kubarych
     [not found] <20000225013416.6567.qmail@web1001.mail.yahoo.com>
2000-02-25  9:42 ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200003060032.TAA10926@marcus.pants.nu \
    --to=flar@pants.nu \
    --cc=dan_bethe@yahoo.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).