Repository navigation
Folder com.apple.container has mismatched bytes when comparing size in Finder vs command line #119
Description
Issue with Finder reporting size on macOS 15
Folder com.apple.container has mismatched bytes when comparing size in Finder vs command line.
Steps to reproduce:
🔴 Finder
- In Finder > View > as List (⌘ 2)
- Enable Size by right clicking on any List column that you have
Issue: Finder shows the folder ~/Library/Application\ Support/com.apple.container with a size of 11 TB
🔴 Get Info
Get info computes 11,550.48 gigabytes
11,550,476,964,910 bytes (17.83 GB on disk) for 328 items
🟢 Terminal
cd ~/Library/Application\ Support/com.apple.container# Summarize disk usage in the current directory
du -hs -- * | sort -hdu Result
Shows that ~/Library/Application\ Support/com.apple.container/snapshots is only 11 gigabytes; different from what Finder is reporting.
0B user-plugins
4.0K apiserver
4.0K plugin-state
4.0K state.json
8.0K networks
14M kernels
657M containers
5.2G content
11G snapshots
System
uname -a
# Darwin something.local 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:48:46 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T8103 arm64sw_vers
# ProductName: macOS
# ProductVersion: 15.5
# BuildVersion: 24F74
Activity
roblabs commentedon Jun 10, 2025
I have no way to test on macOS 26 Beta. Could someone verify the issue on macOS 26 Beta to compare to my results?
I am aware of the stated macOS 15 limitations:
dcantah commentedon Jun 12, 2025
This is not an issue with container itself, but just with how finder vs
dureport size by default (and finder even gives a hint as to the actual size on disk in your output as well). The reason one of them shows as 11TB is because of how we chose to store container images. Every container image we download we place the contents of inside of a 500+GiB sparse file that we use as a block device and attach to the VM. On disk these are typically just the size of the contents of the image, but to some programs that might not check for the real size taken on disk and instead only the apparent size, the files can look quite large :). For example, below is the output with -A forduwhich informs the program to show you the apparent size, followed up bydu's default behavior which displays the actual size taken on disk, which is much much more reasonable:copumpkin commentedon Jan 20, 2026
@dcantah sorry to dig up an old thread here, but what's the "proper" way to clean up those sparse images? My
~/Application Support/com.apple.container/containers/buildkit/rootfs.ext4is a 550GB sparse file, but it seems to have over 100GB of actual data in it too, and its contents are completely opaque to me. Is there a good way to manage that 100+GB of data inside the ext4 without downloading the buildkit thing from scratch every time?