On Sat, 9 Sep 2006, Seid Rudy wrote:

> Michal Suchanek wrote:
>
>> Try the -v switch to scp. Perhaps it will break even more but perhaps
>> it would do the same and show useful information.
>>
>> Thanks
>>
>> Michal
>
>
> hi i tried -v option and found out that scp is getting chopped @ byte
> 40960. Any clue how i can change the byte limit?
>
> debug1: Sending command: scp -v -r -t
> /var/local/rudyserv/wilcox/hr/_sql/
> Entering directory: D0755 0 069999
> Sending file modes: C0644 40960 069999.sql
> Sending file modes: C0644 0 069999.err
> Sending file modes: C0644 0 069999.tst
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> debug1: channel 0: free: client-session, nchannels 1
> debug1: fd 0 clearing O_NONBLOCK
> debug1: fd 1 clearing O_NONBLOCK
> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status 0
>
> rudy@localhost $ ls -al ../sql/069999/069999.sql
> -rw-r--r--  1 seid users 41455 Sep  9 03:18 ../sql/069999/069999.sql

i spawn scp all the time from ruby, with gigantic files of tens of gigs and
have never seen this.  i think this maybe either an os issue or your disk is
failing (though didn't you mention it worked by hand?).

one other possiblity is some pipe filling issue.  by using backticks you are
relying on ruby to read stdout as fast as scp produces it.  i can't imagine
why there would be an issue there, but i'd try your command using something
like

   system "scp #{ src } #{ dst } >#{ log } 2>&1"

are you on windows by any chance?

-a
-- 
what science finds to be nonexistent, we must accept as nonexistent; but what
science merely does not find is a completely different matter... it is quite
clear that there are many, many mysterious things.
- h.h. the 14th dalai lama