Down to what I am asking help with: I am _not_ a C hacker at all, my strenghts are Perl -- if anywhere at all. So I would appreciate your advise before I shoot myself in the foot.
My _advice_ is to miss.
Whoa! Hadn't thought of that ;)
I have seen Kyle's approach of handling the forking directly, and I know I cannot handle that level of complexity. Using something like popen (I am using <http://www.gnu.org/manual/glibc-2.2.3/html_chapter/libc_15.html> as reference) I can probably get away with.
Fine, as long as it is for your own use only.
I don't want to sound more stupid that I naturally am, but could you elaborate? Is this because you generally don't consider this patch interesting for the main trunk or because there are problems with popen() that I should know about?
And, if there are problems with popen, what are those?
One of my concerns is that even though we are setting --whole-file, when I follow the program logic and the output of test runs with -vvv it is still computing CRCs and (at least seems to be) preparing deltas.
Correct. As can be found by a grep for whole_file, whole-file works by operating on an empty blocksum array. Besides we want the CRCs calculated as an extra level of integrity checks.
Ok. Then I'll probably want to fudge the CRC's, although probably Kyle's patch is already taking care of that.
(...)
Second concern: where is the reading and transmission of th file happening? If the do_open is in line 183, where's the read/transmit, map_file() line 202 puts the data uin buf, and then, what? You see, write_int doesn't use buf.
And where is the handle closed?
Look further down, buf is transmitted by match_sums() and fd is closed shortly thereafter.
Yay! match_sums() is actually doing the transmissions. Hmmm.
Let's see what I can glean from that.
Thanks!
martin
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
