issue with Mail.app .emlx files

[cbfiddle]

I have a bunch of old Mail.app message files (.emlx) that contain resource forks. I tried using resource_dasm on one of them, and it produced a .emlx_cmpf_1.bin file. Is this a compressed resource of some kind? Any suggestions on what to do with it?

[fuzziqersoftware]

I'm not familiar with that resource type. This article (https://blog.fosketts.net/2009/09/11/bizarre-hfs-tricks-in-mac-os-x-10-6-snow-leopard/) seems to imply that it could be a trick Apple used to implement per-file compression in HFS+. Are there any other resources in the .emlx files?

[cbfiddle]

There are no other resources.

This may be an example described in: https://wiki.sleuthkit.org/index.php?title=HFS

Is there a command line way of doing a zlib decoding?

On Feb 26, 2023, at 5:16 PM, Martin Michelsen @.***> wrote:

I'm not familiar with that resource type. This article (https://blog.fosketts.net/2009/09/11/bizarre-hfs-tricks-in-mac-os-x-10-6-snow-leopard/) seems to imply that it could be a trick Apple used to implement per-file compression in HFS+. Are there any other resources in the .emlx files?

— Reply to this email directly, view it on GitHub https://github.com/fuzziqersoftware/resource_dasm/issues/69#issuecomment-1445534371, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSSJGOXJBXWC3RIQ6HFUH3WZP56DANCNFSM6AAAAAAVIZITHA. You are receiving this because you authored the thread.

[cbfiddle]

I should add that the one file I have examined also has a data fork that looks reasonable, so perhaps the resource fork is redundant and was somehow left behind after Apple stopped using this compression hack?

On Feb 26, 2023, at 5:16 PM, Martin Michelsen @.***> wrote:

I'm not familiar with that resource type. This article (https://blog.fosketts.net/2009/09/11/bizarre-hfs-tricks-in-mac-os-x-10-6-snow-leopard/) seems to imply that it could be a trick Apple used to implement per-file compression in HFS+. Are there any other resources in the .emlx files?

— Reply to this email directly, view it on GitHub https://github.com/fuzziqersoftware/resource_dasm/issues/69#issuecomment-1445534371, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSSJGOXJBXWC3RIQ6HFUH3WZP56DANCNFSM6AAAAAAVIZITHA. You are receiving this because you authored the thread.

[fuzziqersoftware]

Yeah, it appears the cmpf data is redundant. There probably is a way to decode it via the command line, but I don't know off the top of my head what would work. It seems multiple compression schemes can be used depending on the value of one of the header fields from the xattr... found some technical documentation here which describes the different compression formats.

[Kristine1975]

Github's search found this code: https://github.com/adrianstephens/orbiscrude/blob/fc4e57b2e7a021858eb100491ebaee63fb01e65e/shared/filetypes/container/apple_apfs.cpp#L936

And according to https://wiki.sleuthkit.org/index.php?title=HFS#HFS.2B_File_Compression the icat tool, which is part of sleuthkit, compresses these files:

icat will automatically decompress the file data by default.

[cbfiddle]

Thanks to both of you for the helpful information.

This file is indeed an “HFS” compressed file (on APFS) as revealed by ls -alhO

I found a program afsctool (can be installed using brew) that shows information about compressed files.

File is HFS+/APFS compressed. Compression type: ZLIB in resource fork (4) File content type: com.apple.mail.emlx File size (uncompressed; reported size by Mac OS 10.6+ Finder): 16956 bytes / 17 KB (kilobytes, base-10) File size (compressed): 12288 bytes / 12 KiB Compression savings: 27.5% Number of extended attributes: 2 Total size of extended attribute data: 85 bytes Uncompressed file size reported in compressed header: 16956 bytes

(The reported extended attributes are presumably ones that I installed, unrelated to compression.)

I now understand that the data fork is not a separate copy of the data, it is the virtual result of uncompressing the data in the resource fork.

Getting a uncompressed version of the file is trivial, just use cp.

Uncompressing the ZLIB data directly might be tricky as the resource fork has a non-standard header.