On Apr 26 15:22, Ren? Berber wrote: > 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.
I guess so, too. tcsh on Cygwin reads its input in textmode, that's right, but in the problem of the OP tcsh isn't involved. <rant> The "rsync hangs" problem is not actually a new one. We had these reports already ages ago. However, *nobody* so far having that problem seem to be willing to actually debug this problem and track it down. Grrr. </rant> Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
