SparseBundle file info has incorrect GB size listed

[lalicata]

Hello Again

This MAY be related to my post yesterday titled

“External Hard Drive /System Compatibility Looking Fwd”

But I am not sure.

I hav finished my work in backing up somme files to and old Apple Hard Drive that I had.

It is in a separate enclosure and is connected to my M2 Max using a USB-B to USB-C C1 cable.

It appears to behaving fine.

Except………

I created a sparse bundle file that is 331.79 GB

I know this is about the correct size because when I click on contents of the folder, I see that the 160 documents are taking up about 330.26 GB.

But when I get info on the actual sparseBundle, I see that it says 32.74 GB.

I have ejected and remounted the disc, restarted the MBPro, Shut it down and restarted.

No change.

I ran Disk first aid and got this:

Running First Aid on “Old Apple Drive 750 GB” (disk5s1)

Checking file system and repairing if necessary and if possible.

Volume was successfully unmounted.

Performing fsck_apfs -y -x /dev/rdisk5s1

Checking the container superblock.

Checking the checkpoint with transaction ID 964.

Checking the space manager.

Checking the space manager free queue trees.

Checking the object map.

Checking the encryption key structures.

Checking volume /dev/rdisk5s1.

Checking the APFS volume superblock.

The volume Old Apple Drive 750 GB was formatted by storagekitd (2332.140.13.700.1) and last modified by apfs_kext (2332.140.13.700.1).

Checking the object map.

Checking the snapshot metadata tree.

Checking the snapshot metadata.

Checking snapshot 1 of 2 (com.bombich.ccc.safetynet.806A072E-B0A4-43F7-B1B3-27DC228EAC59.2026-07-09-122821, transaction ID 547)

Checking snapshot 2 of 2 (com.bombich.ccc.806A072E-B0A4-43F7-B1B3-27DC228EAC59.2026-07-09-143818, transaction ID 918)

Checking the document ID tree.

Checking the fsroot tree.

Checking the extent ref tree.

Verifying volume object map space.

Verifying allocated space.

The volume /dev/rdisk5s1 with UUID DC878A39-1C9C-4CCB-A58E-ED0B2356B255 appears to be OK.

File system check exit code is 0.

Restoring the original state found as mounted.

Operation successful.

So, any clue what I need to run / fix to resolve this discrepancy?

Thanks again

Lee

[davidp_tb (David P)]

I don’t trust Finder’s Get Info panel for bundle file sizes, it’s just wrong too often. I’d see if the “du” utility shows the value you’re expecting, e.g. in Terminal:

du -sh {drag the disk image file onto the Terminal window to populate its path}

Then press the Return key to run the command.

[Shamino (David C.)]

Note, however, that du reports the amount of blocks used by files, which isn’t necessarily the full file size.

For instance:

• A 1-byte file will get rounded up to the file system’s block size (maybe 512 bytes, or 4K).
• A sparse file’s size will only report the blocks that are actually used for storage, not the blocks that are not stored.
• Two files that are hard-links to the same data won’t have the data double-counted.
• A copy-on-write clone of a file will only report the shared blocks once.

This is typically, what you want, but it’s important to know, because the number you get will be different from simply adding up the size of all the files.

[mschmitt (Michael Schmitt)]

Your post is missing the images that would show us what’s going on.

What I’m interested in most is exactly what kind of disk image this is. Is it truly a sparse bundle? Is it APFS? Is it encrypted?

One explanation is that it is a compressed disk image, but sparse bundles are not compressed.

[Will_M]

@mschmitt

One explanation is that it is a compressed disk image, but sparse bundles are not compressed.

Veering a bit off-topic, but it might be significant to some readers.

I have a file with the extension .sparseimage (APFS, I believe, and encrypted, I’m sure). When I close it after editing some of the contents, the file modification date changes (as it should, in my opinion). I did have a different file that I believe had the extension .sparsebundle (also APFS, I believe, and encrypted, I’m sure), and it did not get a changed modification date after I edited some of the contents and closed it.

Might this be related to compression?

FWIW, I would much rather get an accurate modification date than an accurate size, although both would be even better.

[Shamino (David C.)]

@Will_M

I have a file with the extension .sparseimage

A sparse image file is a single-file disk image, where unused blocks do not consume actual storage. These files will start out very small, no matter how large their capacity, but they will grow dynamically as new files are added. I don’t know if they will ever shrink when files are removed.

A sparse bundle is not a single file. It is a directory/folder full of files, each one representing a piece (I think 8GB) of the file system’s data. They are intended for use on storage devices that can’t handle (or can’t efficiently handle) very large files, including FAT and various network file systems.

The individual files within a sparse bundle are created and deleted as the storage used by the disk image increases and decreases (as files are added/removed). The space consumed may be less than the configured size of the image, but it may be larger than your files, since storage is allocted as large chunks (those 8 GB files).

But note also that if the image (of any kind) is formatted APFS, then it supports several features that may make a file consume less storage than its size would imply, including:

• Sparse files. Where unused blocks are not stored. They read as zeros and will cause storage to be allocated when they are written.
• Copy-on-write duplication. If you duplicate a file in the Finder or with a tool that uses the corresponding APIs, no new storage is allocated until you start writing to one (or both) of the files. So the storage blocks that haven’t changed are shared by the two files.
• Hard links. Where two or more directory entries refer to the same file. These are used in many places throughout macOS. These are actually features of all Unix-like file systems, including HFS+, and all Linux file systems (ext4, zfs, etc.).

[Will_M]

Thank you.

@Shamino

A sparse bundle is not a single file. It is a directory/folder full of files

That probably explains why the modification date didn’t update when I edited files. I believe a folder’s modification date-time changes when a file (or folder, or other object) is added or deleted, but not when a file in the folder is modified. (Similarly, adding or deleting a file would not change the modification date-time of a folder above the immediately enclosing folder.) Almost always, I would edit files but not add or remove files, especially at the top level. And it would have nothing to do with compression.

[mschmitt (Michael Schmitt)]

I seem to remember hearing about this issue before. But where?

Oh, here it is: Sparsebundle modification date does not change

[Will_M]

Thanks for finding that. My search skills are lacking.