Apple’s virtualization framework and APFS compression do not like each other
The setting: You are running a virtualized GNU/Linux instance on an Apple computer. You are in an APFS folder shared with the guest by way of the virtiofs support built in to Apple’s virtualization framework.
Compress a file (any compressible file, but it helps if it has at least a few non-zero bytes in it or the effect will not be particularly impressive) on the host:
host$ afsctool -vc -T LZFSE example.txt
Make a copy of the file using GNU cp inside the guest:
guest$ cp example.txt copy.txt
Observe that the copy contains only zeros:
guest$ od copy.txt
0000000 000000 000000 000000 000000 000000 000000 000000 000000
*
0016020 000000 000000 000000 000000
0016027
Digging deeper using strace, observe that in the cp run, lseek(3, 0, SEEK_DATA) fails with ENXIO (which indicates that the file is sparse and consists of a single big hole) when the correct return value would be 0:
openat(AT_FDCWD, "example.txt", O_RDONLY) = 3
...
lseek(3, 0, SEEK_DATA) = -1 ENXIO (No such device or address)
The assumptions that GNU cp makes seem to be in line with the specifications of the system calls involved. I infer that there must be a bug somewhere between Linux’s virtiofs driver, Apple’s virtualization framework, and APFS.