Holger Parplies wrote at about 15:02:47 +0200 on Thursday, April 9, 2009:
 > Hi,
 > 
 > Boniforti Flavio wrote on 2009-04-09 14:15:18 +0200 [Re: [BackupPC-users] 
 > Sending csums, cnt = 0, phase = 1 - Backups stuck!]:
 > > Still doing trials, I checked both Linux and Windows boxes what version
 > > of rsync they run.
 > > 
 > > Both tell me:
 > > 
 > > rsync  version 3.0.5  protocol version 30
 > > 
 > > So why is the negotiated protocol "version 28" and not "30"?
 > > Could this be the actual problem? 
 > 
 > I'm no expert on Windoze backups, but from what I've read on this list the
 > problem is *not* the difference in rsync versions, but rather the protocol
 > version 28 being used. You currently can't get around that.
 > 
 > The rsync implementation on the BackupPC server is the Perl module
 > File::RsyncP, not native rsync. You can install whatever version of rsync you
 > like (on the BackupPC server - presuming you're not using it for local
 > backups of the server) or even leave it uninstalled. The only thing of
 > interest is the rsync(d) on the client to be backed up. Jeffrey's point is
 > that the problems we've all been reading about or experiencing for so long
 > with rsync over ssh backups of Windoze clients seem to disappear with 
 > protocol
 > version 30 (which you can only test with native rsync, not BackupPC). Aside
 > from that, they seem to be less frequent (obviously not non-existant, as your
 > case shows) with rsyncd on the Windoze side (and, still, File::RsyncP on the
 > BackupPC server side).
 > 
 > It would be interesting to find out the actual *cause* of the problems. I
 > wouldn't be surprised if it was not protocol version 28 - why should it, it
 > works between Unix hosts - or maybe even the Windows rsync implementation
 > (Cygwin) but rather a detail of option negotiation or option default values.
 > Maybe there is a workaround available (and maybe there isn't). Maybe
 > investigating this would be a waste of time. I don't know. Just sharing my
 > thoughts.

All true. I do believe though that I was able to replicate the problem
when using raw rsync with protocol manually set to 28 (there is a flag that
allows you do to that). So, that would seem to rule out that
"negotiation" is the problem (also rules out BackupPC being the
problem). I did a fair bit of googling and was never able to find out
the *reason* for the problem just that it goes away with protocol 30
and that it can be avoided by using rsyncd.

 > 
 > 
 > So, to summarize, running rsyncd (!) on the Windoze side seems to be the best
 > option, but you're already doing that. Remind me, please, which version of
 > BackupPC and File::RsyncP you are running and what your XferLogLevel is set
 > to. If possible, try a command line rsync with the '--protocol=28' switch to
 > see if native rsync has the same issue or not. Possibly add appropriate
 > switches to increase verbosity. Try to track down on which file it chokes -
 > if it's a file issue at all and not some general permissions issue or
 > something like that (which I feel it looks like, but then again, command line
 > rsync with protocol version 30 would have the same trouble).
 > 
 > I'm sorry that I can't be more helpful. I know how frustrating this kind of
 > problem is.
 > 

I would second Holger's suggestions. Try to narrow it down to a
specific file or path. Keep doing trial-and-error to try to figure out
what makes it hang. What you really want to do is figure out whether
it is a problem with your setup or with your Windows file/filesystem.

 > Regards,
 > Holger
 > 
 > ------------------------------------------------------------------------------
 > This SF.net email is sponsored by:
 > High Quality Requirements in a Collaborative Environment.
 > Download a free trial of Rational Requirements Composer Now!
 > http://p.sf.net/sfu/www-ibm-com
 > _______________________________________________
 > BackupPC-users mailing list
 > BackupPC-users AT lists.sourceforge DOT net
 > List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
 > Wiki:    http://backuppc.wiki.sourceforge.net
 > Project: http://backuppc.sourceforge.net/
 > 

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/