backing up from HFSX volume to HFS+, any issues?

[jed]

Okay thanks,

The thing that's still got me stumped though is that this article says:
HFSX is an extension to HFS Plus to allow additional features that are incompatible with HFS Plus. The only such feature currently defined is case-sensitive filenames

And yet you just said:
Everything is basically HFSX these days...

Can you explain a little further what you mean?
Is HFSX purely HFS+ + case-sensitivity or is there more to it than that, what is the entire definition of HFSX?

[dnanian]

The basic problem here, jed, is that the documentation hasn't been updated since 2004 or so, as you can see by looking at the tech note. And I'm not an Apple file system engineer, so I can't provide you with the "entire definition of HFSX".

When it was introduced, HFSX was originally an extension that allowed case sensitivity. But what I've seemed to see since then (i.e. Leopard) is that volumes seem to 'become' HFSX volumes when directory hard links are used on the volume. There may be other things that 'convert' a drive to HFSX -- or at least away from HFS+ -- as well.

It's not a terribly well documented thing, or at least the documentation seems to be partially incomplete. But in the end, the low-level variant of HFS is not something you need to worry about, which -- in addition to the fact that you're dealing with the same documentation I am, and I can only add things that we've seemed to see along the way -- is why I'm being a bit terse in my responses: the lowest level details of the format are generally designed to be transparent to users.

At a high level, SuperDuper! is happy to copy from a case insensitive to a case sensitive volume (if you use Smart Update). If you use erase-then-copy, we always retain the high-level format selected for the source (e.g. Mac OS Extended (Journaled, Case sensitive, etc)). And, while we'll do it, if you copy from a case sensitive to a case insensitive volume two files with the same name in the same folder can overwrite each other.

So, my advice is to ignore the low-level details of HFS+/HFSX, and deal with high level descriptions. Do not format case sensitive unless you absolutely need to (e.g. typically when you're dealing with source code that comes from case sensitive systems and someone used case sensitivity when naming their files [they're non-unique when insensitive]), and even then I'd isolate its use to non-boot volumes to avoid issues with Mac-native applications that aren't compatible with case sensitivity. Any other low-level 'feature' that needs special file system support will get added automatically (or you'll be prompted to turn something non-destructive on by SuperDuper).

[jed]

When it was introduced, HFSX was originally an extension that allowed case sensitivity. But what I've seemed to see since then (i.e. Leopard) is that volumes seem to 'become' HFSX volumes when directory hard links are used on the volume. There may be other things that 'convert' a drive to HFSX -- or at least away from HFS+ -- as well.

Intriguing so from 10.5.x onwards, even if I choose Mac OS Extended (journaled), Volumes will in time take-on (when hard links are used) attributes that one would associate more with HFSX!

It's not a terribly well documented thing, or at least the documentation seems to be partially incomplete. But in the end, the low-level variant of HFS is not something you need to worry about, which -- in addition to the fact that you're dealing with the same documentation I am, and I can only add things that we've seemed to see along the way -- is why I'm being a bit terse in my responses: the lowest level details of the format are generally designed to be transparent to users.

I suspected this is why you were being so terse, no offense taken!
It's not something that's easy to explain... Particularly since things you've observed are not formal Apple doctrine, & hence leave you vulnerable if you openly assert what you've learned.

At a high level, SuperDuper! is happy to copy from a case insensitive to a case sensitive volume (if you use Smart Update). If you use erase-then-copy, we always retain the high-level format selected for the source (e.g. Mac OS Extended (Journaled, Case sensitive, etc)). And, while we'll do it, if you copy from a case sensitive to a case insensitive volume two files with the same name in the same folder can overwrite each other.

It's re-assuring to know that the app can deal with backups, regardless of the variants used on source/s <---> destination....

So, my advice is to ignore the low-level details of HFS+/HFSX, and deal with high level descriptions. Do not format case sensitive unless you absolutely need to (e.g. typically when you're dealing with source code that comes from case sensitive systems and someone used case sensitivity when naming their files [they're non-unique when insensitive]), and even then I'd isolate its use to non-boot volumes to avoid issues with Mac-native applications that aren't compatible with case sensitivity. Any other low-level 'feature' that needs special file system support will get added automatically (or you'll be prompted to turn something non-destructive on by SuperDuper).

Thanks, for environments like macports etc, I will create an encapsulated volume within the main boot volume that "is" case-sensitive...

[jed]

Hi Dave,

I know my last responses were mostly statements as opposed to Qns.
But can you please confirm whether or not you agree with them all?

Then I will get out of your hair!

Thanks,
Jed

[dnanian]

I'm not trying to be a pain, Jed, but I don't know how to respond to your statements. The only one that seems that it might be respond-able is the last one, where you're indicating you're going to create a case sensitive volume to use macports.

What I've said, above, is that you'd only need to do that if you were working with a project that was silly enough to rely on case sensitivity for its filenames. (I think we can all agree that having two files, one named "foo.h" and one named "Foo.h" in a project that do the same basic thing is kind of foolish.)

It's unlikely that any macports projects would do this, at least without warning in the project description. I haven't run into one myself... but if you do run into one, for some reason, you know what to do.

[jed]

Originally Posted by dnanian

I'm not trying to be a pain, Jed, but I don't know how to respond to your statements. .

So this:

Intriguing so from 10.5.x onwards, even if I choose Mac OS Extended (journaled), Volumes will in time take-on (when hard links are used) attributes that one would associate more with HFSX!

And this:

It's re-assuring to know that the app can deal with backups, regardless of the variants used on source/s <---> destination....

Aren't clear enough? I can re-phrase if you'd prefer, there's no rush!

Cheers,
Jed

[dnanian]

You seem to restating things I've already said, so I don't understand why you want me to say them again, Jed.

[jed]

okay thanks for your support/patience.

all the best,
Jed