BBouncer needs a test for compressed files

[JamesBucanek]

What the subject says: There's no bbouncer test for files with compressed data forks (OS X 10.7+).

I've spent considerable amount of time (correctly) supporting compressed data forks in QRecall, which included soliciting unpublished documentation from Apple. If you need a tool to generate and/or test compressed files, I'll be happy to whip one up for you.

[gingerbeardman]

Would love to read those docs if you'd care to share? Thanks!

I just pushed a new version of afsctool that supports f_type=24 on High Sierra https://github.com/gingerbeardman/afsctool/releases/tag/10.13

[JamesBucanek]

Well, that was a long time ago. LOL

I can't find the info I based this on, but I took a look at my code, and it's pretty straight forward.

Note: you can't create your own compressed files. Only Apple can[1]. The only thing you can do is read, and later duplicate, a compressed file.

1) You can detect that a file is compressed by looking in the file's flags (ATTR_CMN_FLAGS) for the UF_COMPRESSED flag. If this flag is set, the file is compressed. Its data fork is an uncompressed reflection of a hidden extended attribute.

2) Once you find a compressed file, you ignore its data fork. To read it, use the listxattr() to get the list of extended attributes, passing the special XATTR_SHOWCOMPRESSION option so the list includes the hidden compressed attribute. Use getxattr() to read the compressed data (remember to include the XATTR_SHOWCOMPRESSION option in the read call, or it will return "not found").

3) To recreate a compressed file, you reversed the process. Create the new file and write all of its extended attributes using setxattr(), including the hidden one. (This step does not require XATTR_SHOWCOMPRESSION). When finished, set the file's UF_COMPRESSED flag, and the uncompressed data will magically appear in the data fork.

One quirk: I found I had to set the UF_COMPRESSED flag in a separate step, then restore the remaining attributes (mod date, etc.) or else the mod date would get touched. This makes sense, since changing UF_COMPRESSED effectively modifies the data fork.

[1] I've been told the compression is based on zlib, so it might not be that difficult to reverse engineer Apple's compression format, but I've never spent the time to try.

[gingerbeardman]

Thanks very much.

That echoes what what I've read about it, and that I've seen in the source for afsctool (not written by me, but my modified version is linked above)