rsync - Sep 2002 - Rsync Hangs 100% of the time when copying files from win2k machin es to linux

Hey guys, I've been working with rsync for the last couple weeks and I
really need some help here.  Linux to Linux transfers are working
beautifully, but for the life of me I can't get transfers from win2k to
work.  I have the exact problem that was reported by Mark de Jong on Tue, 16
Jul 2002.

I'm using the lastest version of cygwin, with rsync 2.5.5 and ssh 3.5p1 for
my tests.  The problem occurs on every windows box I've tried it on. (Half a
dozen machines, mixed NT 4.0 and Win2k).  It happens every time.  It's very
important to me that I fix this problem but I think I'm going to need some
help.

It happens after I issue the following command from the linux box:

rsync -avx --progress --ignore-errors --delete-excluded --delete -vvv
--exclude-from=system/excludes -e ssh
Administrator@10.0.0.159:/cygdrive/c/WINNT deleteme/

Here is the tail end of it's output: 
recv_generator(WINNT/twain_32/fjscan/fcpa,9712)
recv_generator(WINNT/twain_32/logiscan,9713)
recv_generator(WINNT/twain_32/miitwain,9714)
recv_generator(WINNT/twunk_16.exe,9715)
recv_generator(WINNT/twunk_32.exe,9716)
recv_generator(WINNT/uneng.exe,9717)
recv_generator(WINNT/uninst.exe,9718)
recv_generator(WINNT/upwizun.exe,9719)
recv_generator(WINNT/vb.ini,9720)
recv_generator(WINNT/vbaddin.ini,9721)
recv_generator(WINNT/vmmreg32.dll,9722)
recv_generator(WINNT/vsapi32.dll,9723)
recv_generator(WINNT/win.ini,9724)
recv_generator(WINNT/winhelp.exe,9725)
recv_generator(WINNT/winhlp32.exe,9726)
recv_generator(WINNT/wininit.ini,9727)
recv_generator(WINNT/winrep.exe,9728)
recv_generator(WINNT/wmsetup.log,9729)
recv_generator(WINNT/yacs.log,9730)
generate_files phase=1
 
 It hangs right there indefinatly.   0% processor utilization on both
machines.  After I hit CTRL+C the following prints out:
 
^C_exit_cleanup(code=20, file=rsync.c, line=229): entered
rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229)
_exit_cleanup(code=20, file=rsync.c, line=229): about to call exit(20)
_exit_cleanup(code=20, file=rsync.c, line=229): entered
rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229)
_exit_cleanup(code=20, file=rsync.c, line=229): about to call exit(20)
root@raid:/data/remote-backups#

When it hangs there are 2 process running on the linux box and one on the
windows box.   

When I attach to the first one (pid 7276) on the linux box it's sitting in
select.  If I do a back trace part of the stack doesn't show up (always
showing weird stuff like errno or 0x8 or 0x5 having called select), so I do
a "n" to single step until it emerges from select I'm left with
the
following back trace which makes sense:

#0  writefd_unbuffered (fd=4, buf=0x817f038 "\004%", len=3876) at
io.c:425
#1  0x8057256 in io_flush () at io.c:538
#2  0x8056d35 in readfd (fd=6, buffer=0xbffff824
"????X???\034?\004\b\006",
N=4) at io.c:327
#3  0x8056d7f in read_int (f=6) at io.c:342
#4  0x804b71c in generate_files (f=4, flist=0x807fba8, local_name=0x0,
f_recv=6) at generator.c:524
#5  0x805022f in do_recv (f_in=5, f_out=4, flist=0x807fba8, local_name=0x0)
at main.c:420
#6  0x80506e4 in client_run (f_in=5, f_out=4, pid=7277, argc=1,
argv=0x807f96c) at main.c:599
#7  0x8050ad3 in start_client (argc=2, argv=0x807f968) at main.c:774
#8  0x8050d44 in main (argc=2, argv=0x807f968) at main.c:921
#9  0x4004e853 in __libc_start_main () from /lib/libc.so.6

If I then detach and attach to process number 2 (7284) on the linux box,
then single step until it emerges from select I get this back trace:

#0  read_timeout (fd=5, buf=0x8186b31 "", len=1251) at io.c:204
#1  0x8056b8b in read_loop (fd=5, buf=0x8186018 "\213E??@\030\002",
len=4092) at io.c:253
#2  0x8056c05 in read_unbuffered (fd=5, buf=0x8186018
"\213E??@\030\002",
len=4128) at io.c:279
#3  0x8056d4a in readfd (fd=5, buffer=0x817f038 "MZ\220", N=32768) at
io.c:329
#4  0x8056dfb in read_buf (f=5, buf=0x817f038 "MZ\220", len=32768) at
io.c:374
#5  0x8057d6f in simple_recv_token (f=5, data=0xbfffc73c) at token.c:84
#6  0x805888f in recv_token (f=5, data=0xbfffc73c) at token.c:504
#7  0x804bd6b in receive_data (f_in=5, buf=0x0, fd=4, fname=0x8078360
"WINNT/$NtUninstallQ287687$/icaapi.dll",
    total_size=121616) at receiver.c:224
#8  0x804c486 in recv_files (f_in=5, flist=0x807fba8, local_name=0x0,
f_gen=7) at receiver.c:456
#9  0x8050185 in do_recv (f_in=5, f_out=4, flist=0x807fba8, local_name=0x0)
at main.c:398
#10 0x80506e4 in client_run (f_in=5, f_out=4, pid=7277, argc=1,
argv=0x807f96c) at main.c:599
#11 0x8050ad3 in start_client (argc=2, argv=0x807f968) at main.c:774
#12 0x8050d44 in main (argc=2, argv=0x807f968) at main.c:921
#13 0x4004e853 in __libc_start_main () from /lib/libc.so.6

When I attach to the process running on the windows box, and do a back trace
I get very confused.
(gdb) attach 9552
Attaching to program `/usr/bin/rsync.exe', process 9552
[Switching to thread 9552.0x2bf8]
(gdb) bt
#0  0x77f97705 in _libkernel32_a_iname ()
#1  0x77ea1982 in _libkernel32_a_iname ()
#2  0x77e887dd in _libkernel32_a_iname ()
(gdb) n
Single stepping until exit from function _libkernel32_a_iname,
which has no line number information.
0x78001378 in _libkernel32_a_iname ()
(gdb) bt
#0  0x78001378 in _libkernel32_a_iname ()
#1  0x77f85058 in _libkernel32_a_iname ()
#2  0x77f852cb in _libkernel32_a_iname ()
#3  0x77e8887f in _libkernel32_a_iname ()
#4  0x77ea1991 in _libkernel32_a_iname ()
#5  0x77e887dd in _libkernel32_a_iname ()
(gdb) n
Single stepping until exit from function _libkernel32_a_iname,
which has no line number information.

GDB then hangs up there.   I can't even hit ctrl+C.  I've tried the
cygwin
mailing list for help, but I've yet to get a single response :(  I'm
hoping
this one will be better.

As possible further (but perhaps unrelated information) Mr Jong eventually
gave up and used rsync in daemon mode.  I tried that too, but the rsync
instance on the win2k dies with the following message in the event viewer
part way through the transfer (But it does actually start copying files):
rsync error: error in rsync protocol data stream (code 12) at io.c(463).

	Thankyou for reading this far, if you have any suggestions at all,
please post them.  CC me if you can remember too, I'm not subscribed to the
list, but I'll be reading in the archive.

	David Hinkle