search

linux-apfs / linux-apfs-rw

APFS module for linux, with experimental write support
GNU General Public License v2.0
510 stars 34 forks source link

Accessing resource forks? #53

Open MaddTheSane opened 10 months ago

MaddTheSane commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 8 months ago

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

eafer commented 8 months ago

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.