I have an HFS+ filesystem image recovered from a failing Mac harddrive and can loopback mount it on my Linux machine. How can I access the resource forks for the files in this filesystem from the Linux machine?
(I do not have a Mac with the capacity to store an image this large.)
Add /rsrc to the end of the file name to access the resource fork. I have no I idea where that's documented if anywhere.
Edit:
Just to clarify I was referring to command-line usage; for example cp somefile/rsrc destfile will copy the resouce fork of somefile to a file called destfile.
All command-line functions work this way. I haven't tested it with anything graphical.
This mechanism existed in 2.xx kernels but was removed at some later point. seec https://evilpiepirate.org/git/linux-bcache.git/plain/fs/hfsplus/inode.c
*hfsplus_file_lookup contained the fallowing:
if (HFSPLUS_IS_RSRC(dir) || strcmp(dentry->d_name.name, "rsrc"))
goto out;
This was later removed. It was never documented and may not have worked for all systems. At any rate as noted by "Neil Mayhew" current kernel mainline source no longer does this. Further since OS X apple has stopped creating new resource forks so only legacy files will have them.
.textClipping files.
– Jeff Burdges
Jun 5 '15 at 8:13
I don't think this is possible with the default kernel driver (fs/hfsplus in the kernel sources).
I have an HFS+ volume mounted in Linux and files that have a resource fork. I tried both the commonly-used special filename syntaxes FILENAME/rsrc and FILENAME/..namedfork/rsrc. The former used to work on Mac OS, and the latter works on Mac OS now, but neither works on Linux. They return the error ENOTDIR, "Not a directory". I tried this with files that have a resource fork and no data fork, and files that have both.
I looked through the driver sources and I can see no sign of it being possible to access a resource fork explicitly, either with a special filename syntax or with an ioctl call. The driver does concern itself with resource forks, but only for the purpose of keeping them together with the rest of the file when a file is moved, and deleting them when a file is deleted.
I would love to be proved wrong on this, but I wasn't able to find any information to the contrary.
This won't help you now, but for future reference, there's a utility in the Apple developer tools called SplitForks that turns a single file with a resource fork into two files. The second, hidden, file has ._ prepended to the original filename. It's in AppleDouble format and also contains Finder metadata such as the file's type and creator codes. This is the same format that's used to store Mac-specific data in archive formats like zip and tar, and for transfer using rsync.
SplitForks can work hierarchically on entire directory trees, which can then be transferred to a non-Mac filesystem without loss of data. There's also a companion utility called FixupResourceForks that puts split files back together again if the directory tree is later moved to another Mac.
