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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
