Some C help patching sender.c (from:plain source -> encrypted
destination: rsync + gpg)
ml at nzl.com.ar
Tue Jul 8 05:45:00 EST 2003
jw schultz wrote:
>>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
>>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.
More information about the rsync