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

[D Andrew Reynhout]

On Fri, Mar 12, 2004 at 12:04:36PM -0500, Wesley D Craig wrote:
> My preference is to not adjust the protocol, at least not for HFS+ 
> support.  I don't think it's necessary or particularly desirable.  In 
> particular, I don't see much value in making rsync changes that destroy 
> my ability to store data on arbitrary volumes.  I think it ought to be 
> up to the oddball filesystems to deal with their oddball-ness.

Absolutely.  But I do think it would be necessary to adjust the
protocol to handle either of the above scenarios.

If you convert the file to a single stream (AppleSingle), you
have to change the filename on the destination, else you run the
risk of syncing back and overwriting the source with the modified
file.  Or you could sense the filetype in the stream, but that's
dirty.

If you split the file into multiple files (AppleDouble), you
have to play games with the sort routine, or else you risk FS
corruption.  And it's very inconvenient to be certain that your
sort trick had the desired results.  Unless you know a bit about
the destination FS (specifically what ASCII vals are allowed in
filenames), you might still get it wrong.

> Personally, I'm not out to change the world.  I'd just like a version 
> of rsync that works between Macs & Everyone Else, while preserving a 
> reasonable subset of the data.  As one of the authors of netatalk and 
> radmind, both of which do this with some success, I'm pretty sure it's 
> not too much to ask.

Excuse the iconoclasm.  I was just meandering.  I agree that it's
possible, but I still believe that the changes to rsync would
require a protocol rev.  I tried to imply that ideally, the new
protocol rev would work just fine with older ones unless the sender
*knew* that it needed features (explicit file-IDs) in the new rev.

I'd love to be wrong about requiring a protocol rev.  I just can't
find an opportunity in the code.  I'm still looking.  :-)

Andrew