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

[D Andrew Reynhout]

On Sat, Mar 13, 2004 at 01:23:31PM -0800, Wayne Davison wrote:
> (1) The sender would create the file list pre-munged (with a simpler
> naming scheme) but flagged in such a way that it would know that it had
> to tweak the name back into its unmunged form before opening it.  (This
> solution avoids needing a modified rsync on the receiving side.)

I agree, that is a *much* better idea.

Without modifying the receiving rsync, the files will have to
be saved in a split or streamed form on the destination (even
if the destination is HFS+ capable), but that doesn't seem like
a big loss to me.  

It also means that if you sync the files BACK to the original
sender, you can't safely "convert back" automatically, but I
think that's inescapable, (except in below scenario):

> (2) The sender sends the list unmunged but flagged as "needing to be
> transformed".  Such entries would then be munged sometime after the
> sort.  (This solution has the disadvantage of requiring both sides to be
> upgraded, but it does do less munging, especially if the receiving side
> had native support for the resource-fork files.)

This is good too.  I don't think there's any room left in the
unsigned char to hold another flag, but if a protocol rev is
necessary, widening the flag bits is much more flexible than
explicit file-ids.

Andrew