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

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