[ On Friday, February 8, 2002 at 01:43:40 (+0100), Feico Dillema wrote: ]
> Subject: Re: rsync retrieves garbled files
>
> Then probably rsync.netbsd.org is itself corrupted.

Indeed it seems to be.  I went back through my cron e-mails to check for
evidence of problems appearing in my locally rsync'ed copy of the
repository.  The first evidence appears in the rsync that ran
2002/02/04-16:11 EST.

My rsync driver script also immediately does 'cvs update' runs in
several local working directories.  Following that run it reported:

	cvs [update aborted]: unable to parse /cvs/master/m-NetBSD/main/doc/3RDPARTY,v; `state' not in the expected place

Indeed doc/3RDPARTY,v was "transferred" in that run.

According to PR # pkg/15501 there are apparently LP64 problems in
rsync-2.5.2, and according to the author of that PR it seems the
rsync.netbsd.org runs on an LP64 machine.  I had expected the 2.2.5
install on the server would be reverted and replaced with version 2.4.8
which apparently still works OK on LP64 machines, but which has had the
recent security bugs fixed.  Apparently the repository copy on the
server has not yet been replaced itself though, or if it has then
perhaps the corruption is still being generated by the new rsync on the
server.

Note I have been using rsync-2.5.2 since Jan 19, and it has been working
quite successfully as a client up until then (with apparently successful
daily runs since then to update my local copy of the NetBSD repository).
I've also been using rsync-2.5.2 successfully to mirror the root and usr
filesystems (complete with full source and packages, nearly 110k files,
over 770 MB total) on a couple of production servers to other local
filesystems on those machines.  2.5.2 is the only version that's been
able to do that particular job successfully -- previous versions hung,
even with 'rsync -n'.  So far no corruption has resulted, and I've
checked occasionally with 'diff -r --brief'.


Here's the cron report from the latest run of my rsync script which made
a successful connection.  It indicates at least two more corrupt files.
I've not yet tried to scan more thoroughly for corrupt files.....

START:2002/02/07-16:11:00: rsync
receiving file list ... done
main/modules
main/modules,v
main/val-tags
delete_one: unlink main/CVSROOT/cvsignore: Operation not permitted
delete_one: unlink main/CVSROOT/config: Operation not permitted

Number of files: 164295
Number of files transferred: 3
Total file size: 1829285815 bytes
Total transferred file size: 44849 bytes
Literal data: 44849 bytes
Matched data: 0 bytes
File list size: 2955166
Total bytes written: 157
Total bytes read: 2968694

wrote 157 bytes  read 2968694 bytes  304.26 bytes/sec
total size is 1829285815  speedup is 616.16
DONE:2002/02/07-18:53:38: rsync


START:2002/02/07-18:53:38: cvs update /work/NetBSD/doc

cvs [update aborted]: unable to parse /cvs/master/m-NetBSD/main/doc/3RDPARTY,v; `state' not in the expected place

DONE:2002/02/07-18:53:39: updating /work/NetBSD/doc

START:2002/02/07-18:53:39: cvs update /work/NetBSD/src

cvs [update aborted]: unable to parse /cvs/master/m-NetBSD/main/sharesrc/share/mk/bsd.man.mk,v; `state' not in the expected place

DONE:2002/02/07-19:06:47: updating /work/NetBSD/src

START:2002/02/07-19:06:47: cvs update /work/NetBSD/xsrc


DONE:2002/02/07-19:15:29: updating /work/NetBSD/xsrc

START:2002/02/07-19:15:30: cvs update /work/NetBSD/pkgsrc

? packages-to-upgrade
cvs [update aborted]: unable to parse /cvs/master/m-NetBSD/main/pkgsrc/mk/bsd.pkg.defaults.mk,v; `author' not in the expected place

DONE:2002/02/07-19:28:30: updating /work/NetBSD/pkgsrc


-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>