Hacker News Reader

Comment by gmac | Hacker News Reader

I am all in on the Mac, but I hate APFS — or at least the way it's exposed by the Finder. There's no longer any obvious relationship between deleting stuff and getting disk space back, and at any one time you can find a range of different numbers in different places to tell you how much space is used and how much free.

As it says in the post: "Magic works best when the spectator either knows nothing about the sleight of hand involved, or is another skilled magician". APFS in the Finder makes both impossible.

View on HN

> There's no longer any obvious relationship between deleting stuff and getting disk space back

This is a feature of APFS that Finder can't do much about it: local backups via the APFS snapshotting. APFS maintains a number of local backups for a period of time in a preparation (or, rather, in a hope) to permanently transfer the backups to an external Time Machine, after which the local backups are purged. If there is no external Time Machine set up, the backups will be purged after N days or under the disk pressure (free space is needed urgently).

btrfs in Linux creates file system snapshots in a similar way.

It is possible to entirely disable the APFS snapshots via «tmutil disable», but it will become impossible to restore deleted files, which may or may not be important for some.

The snapshots can also be manually deleted at any time by running a one-liner:

for i in `sudo tmutil listlocalsnapshotdates | grep '^20[0-9][0-9]'`; do sudo tmutil deletelocalsnapshots $i && echo $i deleted; done

What idiot approved this design though?

I have a 512 GB SSD and handle large files often on the go. I've had snapshots taking up 100+ GB with no explanation on my Macbook, just missing space.

Only figured this out when i googled support forums, used 3 party software or went into the terminal.

Apple and their "Magick", confuses regular users and wastes my time.

I fail to see what is wrong with the design. The volume snapshotting is the only way to solve the unsolvable problem of «undeleting» a file in a UNIX file system, after all, and the simplified backup management is the end game here.

Volume snapshotting via checkpointing along with the copy-on-write has been used in UNIX file systems for a very long time and successfully, starting from Veritas VxFS. It is also used in ZFS, in btrfs, bcachefs et al and in some form in the log-structured file systems.

If the default volume snapshot reclamation policy does not work for you, «tmutil» provides a number of controls to fine-tune the behaviour:

1. Disable the snapshotting in perpetuity via «tmutil disable».

2. Exclude select directories from snaphots via «tmutil addexclusion directory1 directory2 directory3»

3. Adjust the quota on how much of the disk space to allot to the snapshosts/backups via «tmutil setquota»

All of the above are one-off commands that, once run, have a permanent to a long lasting effect.

> Only figured this out when i googled support forums, used 3 party software or went into the terminal.

If you want a first-party GUI you can also use Disk Utility: https://support.apple.com/guide/disk-utility/view-apfs-snaps...

This is fantastic advice, thank you. I’ve had the problem for a bit and searched around but never came across this!

> There's no longer any obvious relationship between deleting stuff and getting disk space back

Special file types have been around in other file systems for a long time now.

For instance, Hard Links have been a thing on NTFS disks since the first version of Windows NT.

Deleting a hard link for a file on on an NTFS disk doesn't result in freeing any space, until you delete all the hard links as well as the original file.

As far as I can tell that's not what the issue is. For instance I can delete a file and watch the free space dip 20x the size of the file.

Reply on news.ycombinator.com