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 /..namedfork/rsrc to the end of the file name to access the resource fork. '/rsrc' worked on older kernals. 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.
The '/rsrc' mechanism existed in 2.xx kernels but was removed/changed at some later point. see 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;
It was never documented and may not have worked for all systems. Since OS X apple has stopped creating new resource forks expect in a few specific cases. There is no guarantee that either mechanism will be present in the future.
.textClipping files.
Jun 5, 2015 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.
After some searching I have found a reference to a mount (?) parameter I had forgotten: fork=netatalk. At some point in time, this code apparently has been thrown out of the Linux kernel.
It is still available in Kernel 2.4.18 (Debian Woody = 3), but not with Kernel 2.6.8 (Debian Sarge = 3.1).
Here's one way to do it:
Extract the file from the disk image in MacBinary or BinHex format using hfsutils:
hmount <path to disk image> [partition number] to attach to the disk.hls, hcd <folder name>, and hcopy <file name> . to get the files.humount to detach from the disk image.Use macunpack from macutils (MacBinary), hexbin from macutils (BinHex), or unar (either) to separate out the data and resource forks as separate files.
As for getting individual resources out of the resource fork file, Debian doesn't package it anymore, but it looks like there's a tool for doing that named rsrce that you could build from source.
