Steven Hartland wrote: [snip] > tcsh is the default shell on FreeBSD which is the "recieving" > end in this test yes but I'm a little confused how the shell > could effect the results of rsync? FreeBSD to FreeBSD for FreeBSD > to Windows SFU doesnt have this issue so something specific to > tcsh on cygwin?
Yes, the problem with cvs (actually cvs over ssh) was caused by the shell that starts the remote ssh process. > An example of this failure is: > [log] > rsync -av --progress cygwin1:/testdir/ /testdir/ > receiving file list ... > 1705 files to consider > created directory testdir > / > bf2_w32ded.exe > 0 0% 0.00kB/s 0:00:00 > ***Hung here*** > ^CKilled by signal 2.0.00kB/s 0:00:00 > rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at > rsync.c(242) [receiver] > rsync error: unexplained error (code 255) at rsync.c(242) [generator] > [/log] > > Even though the destination has now been terminated the > rsync process on the cygwin source box is still sitting > there. Checking on the cygwin box no shell is actually > running. Then it must be something different. -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
