Some C help patching sender.c (from:plain source -> encrypted destination: rsync + gpg)

[Martin Langhoff]

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 
>>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