Just over a week ago, when I was looking at problems getting Preview to open PDFs from a double-click, I stumbled across an extended attribute I hadn’t come across before, com.apple.decmpfs. Most days last week I have started drafting an article about this mysterious xattr, only to abandon it and move on to something more informative and less enigmatic. Much as I’d like to reveal all about this, so far I haven’t even drawn a blank, just plenty of claims that contradict my evidence.

Six files

What I can tell you is that it’s very rare, and despite extensive searches of several ~/Documents folders, I have encountered this xattr on only six files, each of which I had used repeatedly during those tests with Preview. They are a couple of PDFs, a couple of RTFs, one Swift source file, and a Pages document, all created where they are now. They’re all small files, the largest of them only 325 KB, and none of them are dataless.

The com.apple.decmpfs xattr on each consists of 36 bytes of binary, with a common start spelling out the letters fpmc, which turns out to be the xattr’s ‘magic’ bytes confirming its type, and a common ending of b735a53b 0d70d062. Between those each is different.

Google search

Google tells me confidently, and repeatedly,
“com.apple.decmpfs is a macOS extended attribute that powers transparent file compression on APFS and HFS+ filesystems. It allows files to be compressed on disk and automatically decompressed in memory when accessed.”

It goes on to explain
“Compressed files with this attribute have an empty data fork on disk. The compressed data, along with a 16-byte compression header, is stored directly within the attribute or the file’s resource fork.”
That’s demonstrably false, as each of these six files has perfectly normal data, no resource fork, and could hardly be compressed down to a uniform 36 bytes.

Google then claims:
“You can see compressed files tagged with the UF_COMPRESSED flag using the ls -lO terminal command.”
Unfortunately, that’s also incorrect. While there is one file in that folder reported by that command as being “compressed”, that isn’t one of the half-dozen bearing a com.apple.decmpfs xattr.

ChatGPT returned similar if rather vaguer answers, none of which is consistent with my observations on those six files.

Sources

Some of Google’s answers are drawn from HackTricks, where there appears to be some confusion between compression and encryption:
“The extended attribute com.apple.decmpfs indicates that the file is stored encrypted, ls -l will report a size of 0 and the compressed data is inside this attribute. Whenever the file is accessed it’ll be decrypted in memory.”
That also makes the claim about being distinguished using ls -lO.

This may have originated in HFS+ back in Mac OS X 10.6 Snow Leopard (2009), according to the sleuthKit Wiki. That also claims that compressed files have an empty data fork, i.e. they are dataless, with the compressed data found in one of three places:

• compressed with zlib and stored in the file’s resource fork, a com.apple.ResourceFork xattr,
• compressed with zlib and stored in the com.apple.decmpfs xattr itself,
• uncompressed and stored in the com.apple.decmpfs xattr immediately after a 16 byte header.

Of course, none of those applies to any of my six files.

Apple’s reference manual for APFS makes no mention of any of this, as you might expect, and the word compression only appears once in the entire document. Searching Apple’s developer documentation is similarly unfruitful.

Otherwise most references to this xattr quote reports from First Aid in Disk Utility, where it’s sometimes reported as an orphan or invalid xattr. None of those responding to these questions seems to have any idea of what the xattr does, and most avoid even mentioning it.

The closest I have come to an explanation comes in some of Apple’s open source code. There’s a whole decmpfs.h header file in the XNU source, for instance, explaining the ‘magic’ header to the xattr, and stating it contains a uint64 giving the logical size of a regular file. It also reveals that the xattr can be attached to an uncompressed file, although it doesn’t suggest how or why that might occur.

The mystery remains

So there are my six ornery files that haven’t been compressed, but have a xattr attached to them indicating their transparent file-system compression. They haven’t been touched by an app or command tool that seems likely to have marked them as being uncompressed compressed files. And whatever disease they’re suffering from doesn’t appear to spread. Perhaps I should see how much I can get for them on eBay, as collectors items?