rsync - Jan 2003 - Latest --files-from patch

If anyone is trying out my --files-from patch, please grab a new version
from here:

    http://www.clari.net/~wayne/rsync-files-from.patch

I fixed a potential bug in the pathname-reading code when pulling files.
This version also sanitizes all read pathnames, as discussed elsewhere.

Remember that this patch is still young, so use it for testing only.

..wayne..

Hi Wayne,

I ran a simple test of your patch at

  http://www.clari.net/~wayne/rsync-files-from.patch

and it worked fine for me.  The performance was just about the
same as for my --source-list patch.

Thanks,
Andy

Hi Wayne,

On Sat, Jan 18, 2003 at 10:39:55AM -0800, Wayne Davison
wrote:
> Cool.  Thanks for trying it out.  If you do a significant amount of
> testing, please let me know so that I can judge when the code has been
> shaken down enough for general use.  I'm going to do some larger tests
> soon myself.
FYI, I'm now using yesterday's CVS tree (which includes your files-from
patch)
in production.  Thanks, it seems to work great.

I am having one problem, however, that is not related to the --files-from
feature.  I was having the same problem with 2.5.6 and my own --source-list
patch.  There's one directory tree that craps out almost every time with
this error:

   rsync: writefd_unbuffered failed to write 174 bytes: phase
"unknown": Broken pipe
   rsync error: error in rsync protocol data stream (code 12) at ../io.c(622)

Here's the command line I'm using:

  rsync -RlHptgoD --numeric-ids \
    --password-file=/etc/rsync_passwd --files-from=/tmp/file.list \
    --null -z -x --stats . remote_mirror::home/dbase

I am using the same script for several other directory trees, and they
work fine.  What's special about this tree is that it contains more
files (around 30,000 to update) and a handful of them are large
(around 200 MB).

I was previously running the same command using the -e ssh option to
start up the remote rsync server, and the rsync would just hang.  Now
that I'm using an rsync server (started by inetd on the remote side),
I get this error.

Can anybody offer any guidance regarding how to debug the problem?
Based on some -v output, it seems to send the filelist OK and sends
one or more files before failing...

Thanks,
Andy