tag 469172 unreproducible
thanks
On Mon 03 Mar 2008, Benjamà Villoslada wrote:
> El Dilluns 03 Març 2008, Paul Slootman va escriure:
> > It sucks that I can't reproduce this, I have a number of systems with
> > different architectures and they all work for me :-/
>
> Kiko is the user #2 that I've mentioned above :)
His problem was a specific problem with using -e ssh together with a
double colon, i.e. single-use daemon server, without passing a config
file explicitly.
Your problem with rsync.net is something else...
> I've remembered that we have one server with Debian Etch and rsync:
>
> $ rsync --version
> rsync version 2.6.9 protocol version 29
> [...]
>
>
> Works fine with my 3.0.0 client:
You showed earlier that rsync.net is using rsync 2.6.8.
However, when I try rsync 3.0.0 -> 2.6.8 it works fine.
I think that without any additional reports and without suitable help
from rsync.net in debugging this, it's not really possible to do
anything about this. The main problem is that the remote rsync simply
goes away without saying anything at all ("0 bytes received"), so the
problem is basically with that specific installation of rsync.
As this is not reproducible for most(?) people (who aren't using
rsync.net), I think I have little choice besides tagging it
unreproducible. I will upload a 3.0.0-2 version with the fix for Kiko's
problem, and will then mark this report as "important", not "grave",
because of the unreproduciblity...
Sorry I can't help more. My request to rsync.net for help was replied
with a no-brainer scripted helldesk answer "don't use -e ssh, that's
redundant" >:-(
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
