"Eric J. Schwertfeger" <[EMAIL PROTECTED]> writes:
> Having gotten lsh for login, fairly stable, I thought I'd try
> remote commands, and basic ones work fine. However, lacking lcp (I'm
> thinking of hacking one up in perl), I tried the following command:
>
> lsh geekazoid.com "cat >lsh-port.tgz" <lsh-port.tgz
>
> Doing the same thing with rsh, if it were allowed, would work, but in this
> case, I get no error message, just "User authentication successful." and
> a few seconds later, I get my shell prompt back, and lsh-port.tgz is a
> 0-length file.
>
> Trying the reverse,
>
> lsh geekazoid.com "cat bbb.data.gz" >bbb.data.gz
>
> Almost works, but the file is truncated. On the other hand,
Now I have done some tests. The following seems to work for me:
[nisse@cuckoo src]$ ./lsh -p 4711 localhost cat /boot/vmlinuz >vmlinuz1
User authentication successful.
[nisse@cuckoo src]$ cmp /boot/vmlinuz vmlinuz1
[nisse@cuckoo src]$ ./lsh < /boot/vmlinuz -p 4711 localhost cat ">`pwd`/vmlinuz2"
User authentication successful.
[nisse@cuckoo src]$ cmp /boot/vmlinuz vmlinuz2
[nisse@cuckoo src]$
(If I leave out the "cat" on the second command, I get an empty file,
for some reason)
> worked fine. It looks like lsh isn't flushing some buffers before packing
> up and closing down, which could also explain the first problem, since the
> file was only 2789 bytes. Hmm, doesn't quite explain the first, unless
> cat is getting killed before it's had the chance to flush the data to
> disk.
For all normal program executions (i.e. everything except errors
before starting up, fatal():s and crashes), both lsh and lshd will
loop around io_iter() until all fd:s are closed, and stdio fd:s that
the process is writing to should not be closed until all buffers are
flushed (there are two functions for marking fd:s for closing:
close_fd(), that closes the fd immediately on the next call to
io_iter, and close_fd_nicely() that stops reading but doesn't close
the file until all buggers are flushed.
To debug this, you can run both lsh and lshd with --debug, and compare
the final CHANNEL_DATA packets in the dumps with the contents close to
the end of the file. Then you can see where the data is lost.
> Is this working for other people, or does it not work yet (as expected?).
It seems to work for me, at least.
/Niels
