How do i enable transparent filesystem compression on any APFS volume? Or check if it is already enabled?
I am expecting something similiar to NTFS compressed attribute.
According to Wiki it should be supported.
Is it per file or volume ?
I am using Mojave 10.14.0, volumes without encryption.
The standard Mojave setup does have APFS compression implemented, but there's no user visible tools that allows you yourself to select files/folders for compression.
It seems that the "ditto" command supplied with macOS is supposed to be able to employ compression on APFS, but it only actually works with HFS+ file systems.
However, even though no user visible tools comes with Mojave - the developer level APIs are actually there. A third party utility exists that uses these APIs to provide a user tool for compressing files/folders:
https://github.com/RJVB/afsctool
You refer to the wikipedia page for your statement that APFS compression is supported. The wikipedia page actually refers to the above mentioned tool for that support.
You can install afsctool from Homebrew by this command:
brew install afsctool
And you can install afsctool from MacPorts by this command:
sudo port install afsctool
You can compress a file or folder like this:
afsctool -c filename
where filename can be the name of a file or a folder.
You can check if a file is compressed, and how much, by this command:
afsctool -v filename
The built-in compression feature of APFS is implemented in the same way as it was on HFS+. That support was introduced with OS X 10.6. Even though it has thus been a part of the macOS system for almost 10 years, it is not really widely used.
In my own experience it just works (HFS+ or APFS - doesn't matter). However, you might run into an edge case where some program reports the file size incorrectly or something like that. I haven't seen any such misbehavior yet. The whole idea with transparent compression is that user programs do not need to know that compression is used at all.
Q How do I enable transparent compression?
You don't. You can't. But keep reading.
This is not "enabled" – for the whole filesystem – and then constantly applied, for example for newly created files.
What you can do is compress transparently individual files and folders.
(One option for this would be using ditto or like in jksoegaard's answer, afsctool, alternative fork)
This distinction is important as it sets limits on what you can compress, effectively.
You can compress your entire home-folder with this.
But that makes not much sense.
In part because many file types are already compressed. JPG, PNG, PDF, zip etc are all formats that usually do have some compression. Compressing them again doesn't save much space but adds a redundant de-compression penalty on accessing them.
In part because how Apple implements its filesystems. Files do not get created and then added to if you amend the content. They get newly created and the old version destroyed. Newly created files don't get and constantly changing files lose all benefit of transparent compression the next time they are written to/committed to the filesystem. This includes all temp-files, cache files, log-files, many preferences etc.
Thus, you should only apply this to files that do not or rarely change.
Those that are read but not written. Application files are the prime candidate for this. And often a great candidate for space saving, as some developers have really atrocious packaging and deployment habits of waste and bloat included.
Apart from afsctool and ditto, GUI tools to achieve this would be MoreSpace Folder Compression (seems to discontinued) or Clusters (v1.7.2, 13$, last updated 2014).
Further, you have to be a bit careful in using this.
Unexpected results are very rare, but exist.
For example, a binary of grep seizes to function and compressing git results in your git-repos becoming unreadable unless you revert that compression (the repositories are still fine).
Some GUI applications do perform some homebrewed tamper detection that might fail if they are compressed in this way. You might never run into one of those, but it's still best to have a backup ready and proceed in smaller steps, not by compressing all at once.
