Thanks guys! Sorry for the delay, but I'm back and tryin to work this out...
So, after being alerted to the missing dash, and discovering that I'd also reversed the outfile/infile designations (where was my brain?), I'm left with the somewhat mysterious
hdiutil: segment: format srps not recognized hdiutil: segment failed - Operation not supported
I did a search on what 'srps' is and found nothing of relevance (I'm pretty sure 'Suggest Retail Price' isn't it) I should mention the source image was created by Bombich's Carbon Copy Cloner (v3.5) and is a bog-standard rw sparseimage. (If I do a read-only write, it returns a .dmg file)
So I'm back to square One...anyone know what the 'srps' format in the error message is referring to? Thanks, Tom
Well, reading the man page for hdiutil offers a couple of ideas. the first (and most likely) problem is in the first paragraph of the description of the segment verb, where it says:
segment a NDIF or UDIF disk image.
sparesimage files are neither of those.
if for some reason that's not the problem, there are two other passages to note. From the USING PERSISTENT SPARSE IMAGES section:
SPARSE images are not recommended for persistent storage on versions of OS X earlier than 10.3.2 and should be avoided in favor of SPARSEBUNDLE images or UDRW images and resize.
and from the COMPATIBILITY section:
In particular, sparse images should not be expected to attach on versions of OS X older than that which created them.
there's no telling what version of sparseimage CCC creates (which would depend on the last time that section of CCC was updated), or even if i creates a different but compatible sparseimage of its own.
I can't imagine he's using ancient api's in his product, especially since v3.5 is the most recent version. But to eliminate the possibility of funky sparses I can try using DI to write out a copy of a sparsebundle source and try that. Thanks again. Onward and forward...
Edit: Oh, ok I get what you meant by the last man page ref. I might be the one with the 'old' OS. I'm actually at 10.6.8 so not so old. And Bombich certifies his product with 10.6.8. I'll check his forum for any info...
yep, that was it. Once I took the CCC .sparseimage and got DI to create a .dmg from it (apparently that's the ONLY filetype DI writes, no matter the type of image chosen) and plugged that back into the Terminal, hdiutil was able to split it into parts.
I will say this, however, the segmentSize written into the command is unlikely to be exactly what you get out. I found there was some overhead added to my 9950Mb segments, as they actually came out to be 10430Mb. So a bit of adjustment was needed to keep them under 10Gb.
This is the 'real world' command, splitting an image on a non-boot partition to the same directory, that finally worked:
MyMachine:~ admin$ hdiutil segment -o /Volumes/sg365e_MEDIA/SG100ej_sysCloud.dmg -segmentSize 9950M /Volumes/sg365e_MEDIA/SG100ej_SYS.dmg
PS: and its quite fast! I split a 64Gb file into 7 parts in about 30 minutes.
As a bit of a postscript to this saga, for anyone else encountering this thread, and who might also be trying to use Carbon Copy Cloner images as a source for hdiutil: it won't work. You *must* use DiskImage to create an image (.dmg) that can be used by hdiutil commands to split into smaller segments (and presumably any other hdiutil task). Just mount the CCC image and get DI to use it to write a .dmg copy of it.
After completing my operation in this thread, I ran a few experiments with CCC (and a small file). No matter what kind of image I wrote with CCC (sparseimage, sparsebundle) hdiutil refused to work with it.