Accessing resource forks?

[MaddTheSane]

Is there any way to have the APFS driver to access resource forks?

Included is a zipped raw image of APFS of ResEdit, an old Mac OS (Classic) application that includes a resource fork (but no data fork as it was only a m68k app), a read-me with data-fork text in Mac Roman and \r newlines, and additional data in the resource fork.
ResEdit 2.1.3 2.img.zip

[eafer]

Internally, we have everything in place to read resource forks, because we need it to work with compressed files. The problem is that Linux doesn't have any standard interface to expose the forks to the user. The closest thing is extended attributes, but those are limited to 64k in size. How big is the fork you need to read? I haven't checked your image yet, but if it's less than 64k you could try getfattr.

[eafer]

I just checked, and the resource fork in the readme appears to be readable if you run:

getfattr --only-values -n osx.com.apple.ResourceFork About\ ResEdit\ 2.1.3

The ResEdit file can't be read though, because it's too big (670639 bytes apparently). There is no straightforward way to deal with this, I guess at some point I need to add a new ioctl to read forks, and then write some userland tool to work with them. I wished Linux didn't have this limitation on xattr sizes.

If this is something you really need right now, it wouldn't be hard to modify the code to read the resource forks instead of the data forks.

[MaddTheSane]

Doing some research, it looks like the maximum size a resource fork can be is 16 MiB.
This was a source of minor consternation, as I noticed later that the resource fork on some data I recovered didn't save the resource forks. This is mainly due to my ignorance of how Linux handles extended attributes.

Sadly, I tried to wipe the drive I was recovering, only to stop once I was hitting write errors.

[eafer]

Doing some research, it looks like the maximum size a resource fork can be is 16 MiB.

There are actually much bigger resource forks in use for compressed files.

This was a source of minor consternation, as I noticed later that the resource fork on some data I recovered didn't save the resource forks. This is mainly due to my ignorance of how Linux handles extended attributes.

How were you recovering the data? Did you get no errors during the copy? That sounds bad.

Sadly, I tried to wipe the drive I was recovering, only to stop once I was hitting write errors.

I'm sorry to hear that. Do you still need help with something?

[MaddTheSane]

If there were errors during the copy, I didn't notice. As I said, I was recovering data from it (macOS wouldn't mount it anymore due to hardware failures).

Do you still need help with something?

More for future reference.

[johnothwolo]

@eafer HFS on linux has a way of accessing resource-forks that I think you could replicate. Check this stack-exchange answer.

[eafer]

Yes, that could be done, but it wouldn't have helped the reporter avoid data loss. The problem is that if we are not exposing the xattrs through the standard interface, I would expect rsync and the like to just ignore them.

[geldot]

It'd be an interesting shortcut to expose resource forks directly to ksmbd, the in-kernel SMB file server, to implement Apple's :AFP_Resource SMB protocol extension natively.

With that and :AFP_AfpInfo handling for Apple-specific metadata, client tooling with Apple SMB support should just work.

Would be neat to support Time Machine backups served by Linux from an external drive that can also be plugged into the Mac directly when needed.

Looks like the complexity in Samba is due to mapping between multiple VFS layers which can be avoided if the ksmbd and apfs modules work together:

https://github.com/samba-team/samba/blob/master/source3/modules/vfs_fruit.c

https://github.com/torvalds/linux/blob/master/fs/smb/server/smb2pdu.c