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

[Wesley D Craig]

On 12 Mar 2004, at 13:08 (or thereabouts), D Andrew Reynhout wrote:
> 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.

rsync uses qsort(3) after building the whole file list.  At least 
that's the case in rsync-2.6.0.  See:

	send_file_list() around line 1066 of flist.c

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.

> Unless you know a bit about
> the destination FS (specifically what ASCII vals are allowed in
> filenames), you might still get it wrong.

Again, I'm not aware that rsync supports ideas like file name 
"munging".  The issue you describe is general, not anything to do 
specifically with supporting, e.g., AppleDouble.

> Another problem with file conversion in-stream is what to do
> with the converted file on the source system.  You could store
> it as a tmp file somewhere, (bad, again creating the different
> filename/sort order problem which seems to require a protocol
> revision to solve) or you could hold it in memory (and possibly
> create enormous memory requirements) and then patch all of the
> functions that get file comparison info (size, ctime, mtime,
> checksum, etc) to deal with memory blocks (even worse, and you
> still create the same problem to safely put the new file into a
> different filename on the destination).

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.

> 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.  :-)

The above sounds like a recipe to me.  The question is, is something 
like this acceptable to the maintainers?

:wes