Engineering case study 02 · Folder sizing

One folder size, three product surfaces.

Disk Usage, Large Folders and File Explorer should not disagree simply because they entered the filesystem through different UI paths. A real-filesystem integration fixture checks that invariant.

4real-filesystem integration tests
3independent size consumers compared
0failed assertions in the current run

The consistency problem

A storage utility often develops several ways to ask “how large is this folder?” A file explorer may use a cache, a disk map may build a tree, and a large-folder scanner may use another traversal. If each path applies different metadata rules, users see conflicting numbers.

Klyr’s integration tests exercise the production filesystem implementations together instead of replacing traversal and metadata access with test doubles.

The real-filesystem fixture

The first fixture writes four payloads to a temporary tree: a file at the root, two nested files, and a payload inside a bundle-like directory. The written payload sizes are 7,000, 13,000, 29,000 and 31,000 bytes.

The expected assertion is not a hard-coded 80,000-byte result. APFS allocation rounds and represents files according to filesystem blocks, so the test asks a more useful question: do the recursive sizer, File Explorer and folder sampler return the same positive allocated-size total?

ConsumerRoleAssertion
Recursive directory sizerProduction allocated-size traversalReturns a positive baseline.
File ExplorerOn-demand recursive size with cacheEquals the baseline.
Folder samplerSamples known folders for overview dataEquals the same baseline.
Disk Usage + Large FoldersTree construction and thresholded resultsEvery emitted child total agrees.

Collapsed branches and cache invalidation

A second test collapses a deeper directory branch and verifies that the collapsed node still equals a direct allocated-size walk. Another test deliberately keeps the parent modification time unchanged after adding a file. It confirms the cached value remains until explicit invalidation, then refreshes to the real filesystem total.

This captures an important design choice: a cache is allowed to be a cache, but removal and refresh workflows must invalidate it deliberately instead of pretending it always reflects concurrent filesystem changes.

Observed result

All four folder-sizing integration tests passed in the current arm64e macOS 14 test run. Disk Usage and Large Folders agreed for every child directory, the scan root was not misreported as a removable child, collapsed sizing matched the direct sizer, and explicit invalidation refreshed the cached total.

What this result does not prove

The fixture is intentionally small and tests consistency, not whole-disk speed. It does not eliminate APFS clone skew, cloud placeholders, concurrent writes, inaccessible locations or differences between directory totals and volume-level accounting. Klyr surfaces those as separate limitations.

Product decision

Klyr uses allocated-size semantics consistently across these surfaces and treats cache invalidation as part of the action workflow. The product separately labels scan completeness because consistent arithmetic over readable files is not evidence that every location was readable.

Read how Klyr analyzes Mac storage and why macOS volume totals can still differ.