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

[D Andrew Reynhout]

On Sat, Mar 13, 2004 at 04:40:59PM -0500, Wesley D Craig wrote:
> qsort is specified in the C89 standard.  The compare function is passed 
> to this routine by rsync.  So if there are sort-order vagaries, they 
> would represent a basic bug in rsync.
> 
> To fake up the second file, I might suggest a change either to 
> make_file() or in send_file_name(), right after make_file() is called.

There aren't sort-order vagaries, per se...the problems were 
created by my approach to adding a file to the flist (adding the
source path, with new struct elements for the destination path.
Done that way, the source path (<filename>/..namedfork/rsrc) had
to sort into the same position as the destination path, which is
why I chose the awkward <filename>.~~~namedfork.rsrc replacement.

Anyway, I think I can avoid that problem now.  I'll be working
on it.

> A tmp file would be "dirty".  Assuming AppleDouble, the header portion 
> of the file is a fixed size, i.e., not enormous.  The actual contents 
> of the resource fork can be treated like any other file.  So the only 
> requirement is for the sender to handle the header specially and to 
> adjust byte offsets in the resource fork by the size of the fixed 
> header.

Yeah, I built a few walls into my thinking about the problem
when I went down the above source/destination-path path.  That's
why I posted my patch...  This looks workable now, as does the
destination ._<filename> mapping.

> The question is, is something like this acceptable to the
> maintainers?

Indeed.  

Thanks for the ideas, everyone.
Andrew