Five Tests You Can Run on Any Mac Storage Tool to Check Its Honesty

Every article in this series has argued the same underlying point: don't take a storage tool's claims on faith when you can check them yourself in a few minutes. This one collects the actual tests — concrete, repeatable, and safe to run in a scratch folder — so you have them in one place rather than scattered across separate discussions of hard links, privacy, and cleanup safety.

Test one: the hard-link double-counting test

This checks whether a tool's combined totals correctly avoid counting the same underlying data twice when it appears under two names.

mkdir -p /tmp/storage-test-hardlink
dd if=/dev/zero of=/tmp/storage-test-hardlink/original bs=1m count=100
ln /tmp/storage-test-hardlink/original /tmp/storage-test-hardlink/linked-copy
du -sh /tmp/storage-test-hardlink

The folder now contains two names for the same 100MB of data. du -sh on most modern implementations should report close to 100MB, not 200MB. Point any GUI tool at the same folder and compare. A tool reporting close to 200MB is counting the same inode twice rather than recognising it as one piece of data referenced from two places.

Clean up with rm -rf /tmp/storage-test-hardlink when done.

Test two: the sparse file test

A sparse file has "holes" — regions the filesystem hasn't actually allocated — so its nominal size can be far larger than the space it actually occupies on disk. This test checks whether a tool distinguishes the two.

mkdir -p /tmp/storage-test-sparse
truncate -s 1g /tmp/storage-test-sparse/sparse-file
du -sh /tmp/storage-test-sparse
ls -lh /tmp/storage-test-sparse

truncate -s 1g creates a file that reports as 1GB in size (visible via ls -lh, and in Finder's Get Info) but that occupies little to no actual disk space, since no data has been written into it. du -sh, which by default reports actual disk usage rather than nominal size, should show a number far smaller than 1GB. A storage tool that reports this file as consuming a full gigabyte of your disk is reporting nominal size rather than actual usage, which will make its totals disagree with what df -h shows as genuinely used.

Clean up with rm -rf /tmp/storage-test-sparse.

Test three: package interior test

This checks whether a tool can see inside package-style bundles rather than treating them as a single opaque item.

Create a simple fake bundle structure:

mkdir -p /tmp/storage-test-package/fake.bundle/Contents
dd if=/dev/zero of=/tmp/storage-test-package/fake.bundle/Contents/big-file bs=1m count=50

In Finder, a folder with certain extensions and internal structures (like a real .app or .fcpbundle) is presented as a single double-clickable item rather than a browsable folder. A genuinely thorough storage tool should still let you browse into a package-style directory in its own interface and see that the 50MB is specifically inside Contents, rather than only reporting fake.bundle as one 50MB blob with no further detail available.

Clean up with rm -rf /tmp/storage-test-package.

Test four: the permission-denied honesty test

This checks whether a tool tells you when it couldn't read something, rather than reporting it as empty.

Create a folder and remove your own read permission from it:

mkdir -p /tmp/storage-test-permission/blocked
touch /tmp/storage-test-permission/blocked/secret-file
chmod 000 /tmp/storage-test-permission/blocked

Point a storage tool at /tmp/storage-test-permission and see how it represents the blocked subfolder. It should indicate that it could not read that folder's contents — not report it as 0 bytes with no distinguishing indication, which would be indistinguishable from an actually empty folder. Restore permissions and clean up afterward:

chmod 755 /tmp/storage-test-permission/blocked
rm -rf /tmp/storage-test-permission

Test five: the network activity monitor test

This is the one covered in depth elsewhere in this series, included here for completeness: install a per-app firewall tool such as Little Snitch (or the free, open-source LuLu), open it, and then use your storage tool normally — scan a real folder, browse into it, run a search. A tool with genuinely no network code should trigger no connection attempts at all during this process. Anything that does appear is worth investigating against the tool's own documentation about what it expects to connect to and why.

A sixth, non-technical test: the confirmation dialog read-through

Not every useful test requires a terminal. One of the simplest checks costs nothing but attention: the next time a storage tool offers to clean something up, actually read the confirmation dialog word for word before clicking anything. Does it name specific files and folders, or only a category and a total? Does it say "move to Trash" or does it say "delete" or "remove" without specifying which? Does it give you a way to deselect individual items, or is it all-or-nothing? This test takes thirty seconds and tells you more about a tool's real safety posture in practice than any specification sheet or marketing page, because it's the actual moment where a mistake would happen if the tool's design encourages one.

Keep a record of what each test showed

If you're evaluating more than one tool, it's worth jotting down what each of the six tests actually showed for each candidate, since it's easy to forget the specifics after switching between several applications in one sitting. A simple table — tool name against each test's pass or fail — turns an afternoon of scattered impressions into something you can actually compare and refer back to later, including well after you've made a decision and want to remember why.

Why running these yourself matters

None of these five tests require programming knowledge beyond copying a command into Terminal, and none of them touch real data — every test above operates entirely inside a disposable /tmp folder you create and delete yourself. What they buy you is independence from marketing language: instead of trusting a claim about hard-link handling, sparse file awareness, package browsing, permission honesty, or network behaviour, you get a direct, repeatable answer on your own machine.

Where VolumeLens fits

We built VolumeLens expecting people to run tests exactly like these, which is why hard links are counted once, sparse and compressed files are flagged rather than reported at nominal size, folders macOS refused to read are labelled rather than zeroed, and the app has no network code to trigger in the first place. If you run any of the five tests above against VolumeLens, the result should match what this article describes. Download VolumeLens and try them yourself, or read more about how the app is built on the features page.