Jan Alphenaar wrote:
Julian,
Both scenario's you describe are the way rsync should behave, but it
does not. Let me just describe how case a can be reproduced.
Take a large zip file, my file is now 100MB, and encrypt it with
rsyncrypto. Now rename that file to 1.zip. Encrypt this file again and
rename the encrypted file to 2.zip. Both files should be the same
(except the first blocks), right ?
That really depends on whether you encrypted them using the same session
key.
Hope it is a bit more clear now.
Regards,
Jan
Here is what I'm testing.
dd if=/dev/urandom of=/tmp/test bs=$((1024*1024)) count=100
Create a 100MB random file.
s...@sunlap:/tmp$ rsyncrypto test test1.enc test.key
/usr/share/doc/rsyncrypto/examples/tests/cert.crt
s...@sunlap:/tmp$ rsyncrypto test test2.enc test.key
/usr/share/doc/rsyncrypto/examples/tests/cert.crt
Create two files which are (almost) identical. vbindiff confirms this -
the two files have a different header, but several bytes into the file
they become identical and remain so until the end of the file.
If this is your situation, rsyncrypto is working as advertised. If rsync
does not do the expected thing with this case (for example, because it
does not apply the rsync algorithm to files that start off differently
but become identical in cases of partial transfers), then this is a
rsync bug, and has nothing to do with rsyncrypto.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Rsyncrypto-devel mailing list
Rsyncrypto-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
