On 28 Sep 2000, Niels M�ller wrote:
> Jeff Bailey <[EMAIL PROTECTED]> writes:
>
> > Some history for you: The 'guile' module is the first one on subversions
> > where people are using lsh. I'm troubleshooting to figure out why people
> > were reporting data loss from 'cvs diff'. Dirk has volunteered to help
> > us troubleshoot if this is an lsh problem, and also has 'ssh' access as
> > well for comparison.
>
> Sorry for the late reply, but I don't quite know how to attack this
> problem.
>
> I kind of suspect that it has to with non-blocking i/o; the lsh
> process sets all its fd:s, including stdio, in nonblocking mode.
> However, cvs ought to set lsh's stdio to some pipes, so that shouldn't
> matter. Knowing how all involved fd:s and pipes are glued together
> might help.
Hmmm. How could I help you here? Do you have any example code that I
should try for you?
> Another thing that might shed some light is running lsh with --debug
> (i.e. CVS_RSH=lsh-wrapper, where lsh-wrapper is some program that runs
> lsh --debug and redirects its stderr to a file). By looking at the
> dumped traffic, it should be possible to figure out where the data is
> lost. Switching off encryption (by -c none on both sides) might be
> useful too, but make sure that you don't use password auth if you do
> that.
When I use the following wrapper file:
#!/bin/bash
lsh --debug $* 2>lsh.errlog
then everything works. If I use lsh directly, it doesn't. Thus, it seems
that I can't provide useful information this way :-(
> Finally, if it is possible to trig the bug with something simpler than
> cvs (lsh server some-script |less), that might also help.
I don't know which kind of service could be tried this way. The only
thing I am using is cvs. Maybe Jeff Bailey could make some suggestions
about some simple thing that may be run this way...
Best regards
Dirk
