Unless you get an answer from someone who has tried this before, a quick bit of Googling seems to suggest that you're playing with fire.
While this question on SuperUser suggests that more recent versions of
rsync support resource forks, I see no such mention in any of the upstream changelogs. It may be specific to the OS X version of
Tread very carefully here:
- Most Linux programs won't have any awareness of resource forks.
- Resource forks exposed by the kernel driver will appear to the operating system as virtual "directories". Resource forks are definitely not directories, so any program that interprets them as anything other than resource forks will not copy what you mean for them to.
The one thing I can't seem to find is whether or not a filesystem call to directly copy a single file will catch the edge case of transferring everything intact if the target is the same type of filesystem. This is where my understanding of kernel system calls gets hazy. I want to say it's not likely given the implementation, as
cp -R, unpatched
rsync, etc. would completely freak out trying to replicate the directory structure.
Short of getting a better answer than mine, you're probably better off using some type of "container format" to copy a collection of data intact as a single file. This would require that you hook the drive back up to something that implements native HFS+, and that you have enough space for the extra file. The posts that I linked offer some suggestions.