some clarity Re: HFS+ resource forks: WIP patch included

D Andrew Reynhout reynhout at
Wed Mar 10 19:28:29 GMT 2004

On Wed, Mar 10, 2004 at 01:57:41PM -0500, Kevin Alexander Boyd wrote:
> There are chflags and finder metadata to be mindful of as well.

Yes.  I forgot to mention it, but for the moment, I'm accepting
the loss of creator/type, icon, etc.  For now, all of that requires
manual repair upon restoration. I would have tried to shoehorn it
in, but I haven't thought of a way to do it without creating a new
file on the local FS yet.  (part of the flist parity problem (and
protocol compatibility preservation issue) I ran into...which may
be mostly my lack of understanding..)

> On your website, you state:
> "There are a few ways to approach the problem.  RsyncX and rsync_hfs
> (by Kevin Boyd) turn the files into one of the single-fork formats
> of olde (e.g.: macbinary, applesingle, etc) and transfer them that
> way, then unwrap them on the other side.  This method requires a
> HFS+ filesystem on the both sides, so it didn't suit my needs."
> This is untrue. rsync_hfs does not encode or split the file at all,

Ahh.  Thanks.  I knew that info was questionable, but I hadn't 
researched it enough yet, so I didn't know what to replace it with.
I'll fix it presently.  I meant to add a link too.

Anyway, that explains why adding cross-FS support to rsync_hfs
isn't as simple as it might be.

BTW, I'm very aware that creating my own convention for dealing
with this problem is presumptuous at best, ill-conceived at worst.
But I first ran into the resource fork problem on HFS+ two years
ago (when I first became aware that resource forks somehow still
existed on OS X!).  I switched all of my backup processes to use
rsync exclusively six years ago, and it became a choice between
patching rsync and eventually losing data due to my inconsistent
practice of the extra step for the OS X machines (burning DVD-Rs
of dual-fork files(!)..doesn't scale well.).

So I'm only using this for disaster-recovery purposes.  As such,
I'm more willing to take certain hits (like the Finder metadata
mentioned above, which can be fixed manually (or in some cases
ignored)) than other people might be.


More information about the rsync mailing list