os x hdiutil expert needed

I am writing a script that using the "Total Bytes" field from hdiutil imageinfo -plist <file>. My intention is to get the total mounted size of a compressed dmg. It works for some images, but sometimes it doesn't seem to match up, particularly with larger (over 1 gb) images. Can anybody explain why this is happening, and if there is a more accurate way to get the mounted size through the command line?

Without seeing your code I can't possibly tell why it's not working.

This first part of the script is supposed to get the total size of the disk image when mounted:

os=0
for i in ${DMGLIST[@]} #This array contains a list of .dmg files
do
    DMGSIZES[pos]=$(hdiutil imageinfo -plist $i | awk -F"[<>]" 'a{print $3; exit}$2=="key"&&$3=="Total Bytes"{a=1}')
	let pos++
done
unset pos
echo;echo

This part of the script restores images to their corresponding partitions. The size of the partitions is based on the total size of the mounted disk image.

a=0

for i in ${DMGLIST[@]}
	do

	echo "Reimaging the "${DMGLISTshort[a]}" Partition..."

	asr --source "$i" --target /Volumes/"${DMGLISTshort[a]}" --erase --noverify --noprompt --disableOwners
	sleep 2

	let a++

osx has a fairly old version of bash if I recall, one which still uses 32-bit integers for number calculations. Try keeping a count of blocks or megabytes instead of raw bytes.

Unfortunately I don't think that hdiutil reports a block count for disk images. Do you know of another way to get this information? I could find it for the compressed image file, but not for the size the image is when mounted.

Do you mean "the total uncompressed size of a compressed dmg" ?

Please post the exact version of your O/S (blanking anything confidential like machine names with X's).

uname -a

Please post sample output from your hdiutil command for the largest file involved:

hdiutil imageinfo -plist filename

What are the mathematical calculations for this? Are any of these "partitions" larger than exactly 2 Gb ?

For an image whose compressed size is 3.05 gb

/array>
	<key>Size Information</key>
	<dict>
		<key>CUDIFEncoding-bytes-in-use</key>
		<integer>3045130752</integer>
		<key>CUDIFEncoding-bytes-total</key>
		<integer>3045130752</integer>
		<key>CUDIFEncoding-bytes-wasted</key>
		<integer>0</integer>
		<key>Compressed Bytes</key>
		<integer>3045130752</integer>
		<key>Compressed Ratio</key>
		<real>1</real>
		<key>Sector Count</key>
		<integer>6136138</integer>
		<key>Total Bytes</key>
		<integer>3141702656</integer>
		<key>Total Empty Bytes</key>
		<integer>96571904</integer>
		<key>Total Non-Empty Bytes</key>
		<integer>3045130752</integer>

The important field here is "Total Bytes." There are no mathematical calculations, it is parsed directly from the hdiutil -plist. Pretty much every image I have is larger than 2 gb. These are service diagnostics, and each one is basically a fully-functioning bootable OS. I need to get multiple drives set up with 30+ of these images, which is why I wrote the script. Everything works perfectly except this one operation. Hopefully I (or we!) can find a solution!

---------- Post updated at 06:38 PM ---------- Previous update was at 06:24 PM ----------

I'm thinking that we aren't going to find a way to fix this issue directly. Unless anyone has any other suggestions, I think I might have to look at finding a way to round the size up to the nearest GB size and use that instead. I don't think I can do that in bash though, but I'm pretty sure I can figure out how to do it an awk. I know this isn't the scripting forum, but if one of you has any insight on how to do that I'd appreciate it.

Of course, I'm still open to any other solutions anyone comes up with.

Not posting your O/S and Shell details is driving me nuts!

We really need to know whether the O/S Shell can cope with numbers above 2147483647 ((2 x 1024 x 1024 x 1024) -1 ). i.e. a 32-bit O/S.
The unix bc command can cope with much larger numbers.

I give up.

1 Like

My apologies, I was at work and trying to get this done in between things. Thanks for trying to help anyway!

I ended up just converting to GB and rounding up to the nearest whole number. Not ideal, but it will work for now. I will try to find out about my shell (bash) for future reference. Thanks again!

FWIW, this is bash 3.2.48 on OSX 10.7

$ echo $(( 2 ** 63 - 1 ))
9223372036854775807
1 Like

So that was not the problem. I think the issue I that hdiutil is not reporting the exact number I am looking for.

Furthermore, I don't know enough to know if the uncompressed size of a dmg is exactly equivalent to the space on a partition required to be able to restore the image to that partition. Other than actually mounting the disk image and finding the size with diskutil or uncompressing each image, I don't know of its possible to get this info.