Repository navigation
[Bug]: buildkit ext4 files (initfs and rootfs) are bigger (1,1 TB) than my whole disk on apfs #497
Description
I have done the following
- I have searched the existing issues
- If possible, I've reproduced the issue using the 'main' branch of this project
Steps to reproduce
Download and Installing 0.3
Current behavior
The buildkit ext4 files (initfs and rootfs, see screenshots) are bigger together (1,1 TB) than my whole filesystem(apfs):
I found it, since Time Machine was taking forever, a look in activity monitor of the backupd shows me that it was coping the init.ext4 file for ours. Then I looked how big the file was.
Expected behavior
Reasonable files size of these files, that Time Machine can simply copy it in time.
Environment
- OS: Sequio 15.6
- Xcode: non
- Container: 0.3
- MacBook Pro M2Relevant log output
see screenshots; I forgot to make a screenshot of the open files of the backupdCode of Conduct
- I agree to follow this project's Code of Conduct
Reacted by Samir Shetty
Activity
jglogan commentedon Aug 14, 2025
Closed as duplicate of #119. Finder reports the total size of the (sparse) file and the number of bytes used on disk which is lower. You can also use
du,ls -s, orls -lhsto see the on-disk usage.com.apple.containerhas mismatched bytes when comparing size in Finder vs command line #119pr-ju commentedon Aug 15, 2025
Closing this issue does not solve the problem that Time Machine is stuck on those file and does not continue (for more than one day in my, till I broke it up) this is the real issue.
You should reopen this issue, since it might affect all people who want to use container and also do a Time Machine backup. Nobody will install it, if one knows that Time Machine will not work anymore.
wlan0 commentedon Aug 15, 2025
@pr-ju
The container’s disk image is a sparse file, so the “1 TB” you’re seeing is its apparent size, not what it occupies on disk.
On modern macOS (Big Sur+), Time Machine backs up to APFS (including network backups, which store an APFS volume inside a sparsebundle). In that setup, sparse files stay sparse in the backup.
Time Machine only copies the blocks that actually exist and will restore the file as sparse again. It won’t try to push 1 TB to your backup target because the unused “holes” aren’t copied.
If the backup target is the older HFS+ format, sparse files do expand to their full size in backups. That’s one reason Apple moved Time Machine to APFS.
The simplest fix is to exclude the container app support bundle from Time Machine backup, since this directory will be recreated on the fly if it doesn’t exist, it is safe to do so
jglogan commentedon Aug 15, 2025
@pr-ju Just a quick check, are you able to reopen the issue yourself?
Let us know if you weren't able to, we definitely want you to be able to do that if you think it should be reopened.
With your Time Machine device attached, could you run this and see whether your Time Machine volume is APFS or HFS+?
jglogan commentedon Aug 15, 2025
@wlan0 possibly a duplicate of #404 (comment)
pr-ju commentedon Aug 16, 2025
External backup volume is HFS+. Is It seems indeed very similar to the linked bug. I can test on a fresh APFS volume later on.
pr-ju commentedon Aug 17, 2025
I did two tests. One with a newly create TM apfs disk. There it went smoothly. The other test with an external TM apfs disk that I already used some time it stuck again.
Workaround with excluding "~/Library/Application Support/com.apple.container” works in all cases. So I guess the bug should become a "Known Issue."
On the long run, of course, one might also to be able to backup some containers of oneself that are "operation critical"
crosbymichael commentedon Aug 18, 2025
We should add this to the FAQ or part of a known issue section helping users exclude this directory from TM.
kohlschuetter commentedon Aug 22, 2025
This is a duplicate of #404.
It also has a proposed fix that doesn't require users to manually add a Time Machine exclusion
jglogan commentedon Oct 22, 2026
@pr-ju That's guaranteed to be a mess without exclusions, as HFS+ doesn't support sparse files.
Let's leave this as a companion to #404, which relates more to TM backup to NAS IIRC. This issue will cover TM backup to HFS+.
#2412 adds TM exclusions to files; we need to make sure that those exclusions cover all the sparse filesystem images we generate for it to address both of these issues properly.