some clarity Re: HFS+ resource forks: WIP patch included
D Andrew Reynhout
reynhout at quesera.com
Sun Mar 14 18:01:18 GMT 2004
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
More information about the rsync
mailing list