It's quite common for app bundles to be distributed in .zip files, and to be stored on-disk as filesystem-compressed files. However, having them both appears to be an edge case that's broken for at least two major releases! (FB19048357, FB19329524)
I'd expect a simple ditto -x -k appbundle.zip ~/Applications (-x: extract, -k: work on a zip file) to work. Instead it spits out countless errors and leaves 0 Byte files in the aftermath 😭
Please fix.
EDIT: ditto -x -k --hfsCompression appbundle.zip ~/Applications
It's quite common for app bundles to be distributed in .zip files, and to be stored on-disk as filesystem-compressed files. However, having them both appears to be an edge case that's broken for at least two major releases! (FB19048357, FB19329524)
Let me start with a more basic question, namely, what are you actually trying to do here? The filesystems support for compressed files is a fairly obscure implementation detail that we never formally documented and never intended for widespread use. Note, for example, that its implementation is incompatible with custom icons*. Similarly, support for them in the broader ecosystem is inconsistent, and copying them incorrectly will result in a non-functional file. That isn't an issue for the role the system intended them for**, but it is a problem in broader usage.
*Compressed files "repurposed" the resource forks, while custom file icons use essentially the same resource fork-based architecture that they used on macOS Classic.
**Basically, further reducing the size of very small read-only data files.
Moving to the specific command here:
I'd expect a simple ditto -x -k appbundle.zip ~/Applications (-x: extract, -k: work on a zip file) to work.
To be honest, it actually worked better than I was expecting. What I expected was that it would write out the resource fork data while dropping the attribute that marks a file as compressed, leaving you with a compressed but broken file. It appears what it's actually doing is writing the uncompressed data to the data fork, then erroring out trying to deal with the compressed data. I'm not entirely sure how that's playing out, but I suspect what's actually happened is that the original zip archive actually saved the files in their uncompressed state, but also preserved the file attribute that marked them as "compressed". Note that the file uncompressed just fine with archive utility, but produces an uncompressed copy.
The summary here is that if you choose to use this file system feature, you may also need to work around parts of the system that don't handle it properly. File-level compression isn't a full part of the system and never has been.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
