Why does my .sparseimage file size not reflect the amount of data insde of it?

Are the files inside the .sparseimage, also sparse?

Using Applications -> Utilities -> Terminal you should be able to see the file allocations

/bin/ls -sl /path/to/your/bin.sparseimage. The value in column 1 is the allocated storage in kilobytes. The file system allocates storage in increments of 4096 bytes (4K).

Then mounting the bin.sparseimage, look at

/bin/ls -slR /Volumes/whatever.name.it.is.mounted.under/

This should list all the files inside your bin.sparseimage, and again the numbers in column 1 are the allocated storage for each file in kilobytes.

I was wrong about the column 1 units. They are a sector count with each sector being 512 bytes. So 8386880 * 512 = 4,294,082,560 (approx 4GB). So that is the actual amount of space being used by the bin.sparseimage.

You would also suppose to look at the column 1 values inside the sparseimage so make sure those files were using what you think they were (I've added an @ to the options so we can also see if any of the files inside the bin.sparseimage have extend attributes attached to them - it may or may not be useful, but better to get it now, then ask later):

/bin/ls -slR@ /Volumes/whatever.name.it.is.mounted.under/

And yes a sparseimage (and all the other Mac OS X image files) are containerized file systems, like an archive.

Without the above /bin/ls -slR@ output, it is difficult to guess what is inside the bin.sparseimage.

I'm also expecting Terminal and Finder to agree on the file size

Well from what I'm seeing the Terminal output does agree with the Finder. What we don't know is what is inside the sparseimage

First you were suppose to use

/bin/ls -slR@ /Volumes/Bin/

Notice the 's', which would give the actual allocation for each file inside the .sparseimage

Second, you have only showed 3 directories, which is not going to tell us anything about how much space each file inside the .sparseimage thinks it is taking up.

A .sparseimage on the outside is "Just a Regular File". From the outside, there is nothing special about it. The "Sparse" part of its name means it can take advantage of the host's file system's ability to create what are called sparse files. That to say, if nothing is written to a range of the file, than the host file system does not need to allocate storage for that range, but later if something is written to that range, the host file system will allocate storage. This behavior is idea for .sparseimage files, as the inside is yet another file system, and it can be configured so its maximum potential size is much bigger than the amount of storage needed to initially create the .sparseimage file, and as the inner file system grows, the .sparseimage container file can have more stroage allocated to it by the host file system. That means you do not need to preallocate the maximum amount of storage for the maximum potential size. Much more strorage efficient.

However, that being said, the bin.sparseimage file using /bin/ls -sl@ will tell you exactly how much physical storage was allocated to the .sparseimage file.

I trust this value, so I unsure of what is inside the .sparseimage container file. Which is why I wanted to see /bin/ls -slR@ /Volumes/Bin so we could see if ...

a) the physical allocation for each individual file (not directories) matched the byte size of the file (I guess a moderate sample of real files would be good enough, but make that a hundred or so, and not just the few directories).

b) I would like to confirm that the /bin/ls command thinks they are real files, and not Mac OS X aliases, or Unix symlinks. Aliases and symlinks would just poing back to the originals on the boot disk, and take up very little space in the .sparseimage

c) other.