[patch] starting byte offset in transfers with scp

[Alejandro Forero Cuervo]

Hi.

I made  a patch  for OpenSSH  3.6.1 that makes  scp receive  a -s
option causing  file tranfers  to start  at a  specified position
(byte offset).  This is useful to resume broken file transfers.

If the  position specified is  negative, the transfer  will start
after the last byte in the local version of the file.

For example,  I am regularly  having to  update my local  copy of
some  logs using  scp.  Rather  than transfer  the logs  entirely
every time, I will do:

$ scp -s -1 user at server:/path/log server.log

scp will check  the size for the (local) server.log  file and use
that  as  the  starting  position for  the  transfer,  thus  only
transfering whatever  has been appended  after I last  updated my
copy.

Previously I had to use something like:

$ ssh -C user at server "dd bs=1 skip=`du -b server.log | cut -f1` if=/path/log" >>server.log

It is also possible to specify a given byte offset as in:

$ scp -s 5000 user at server:/path/log server.log

As  I said,  when  the offset  is negative,  scp  will check  the
filesize for the  local version of the file.  This  makes it easy
to resume  broken downloads (as  the first example shows)  but is
not very  useful for  local to  remote transfers  (uploads).  For
those one must somehow figure the  file size at the remote server
and specify it explicitly.

The value of  -s is ignored for local to  local transfers.  It is
respected for  all other  transfers (local  to remote,  remote to
local and remote to remote).

For this functionality  to work all the versions  of scp involved
must be  patched.  If any  is unpatched  and the -s  parameter is
specified,  the usage  error will  be given  to the  user.  These
problems do not occur  if the -s parameter is not  used (or if it
is used with a value of 0).

The patch is available at

    <http://bachue.com/alejo/patches/patch-openssh-3.6.1-scp-resume>

with MD5 1e188e93bb134fc92f97a83205fe2853.

Please  apply  it  to  the   official  version  if  you  deem  it
appropriate.   I  would like  to  see  scp servers  support  this
functionality.

Thank you.

Alejo.
http://bachue.com/alejo

Ps: I had already sent a message like this to the list, and I got

    May 27 00:56:21 azul postfix/smtp[32747]: 45D554105:
    to=<openssh-unix-dev at mindrot.org>,
    relay=mail1.mindrot.org[203.36.198.97], delay=6, status=sent
    (250 Ok: queued as 9363527C189)

but I  failed to receive  it (or a message  about it) and  see it
appear in the archives and thus decided I would resend it.

--
The mere formulation of a problem is far more essential than its solution.
      -- Albert Einstein.

$0='!/sfldbi!yjoV0msfQ!sfiupob!utvK'x44;print map{("\e[7m \e[0m",chr ord
(chop$0)-1)[$_].("\n")[++$i%77]}split//,unpack'B*',pack'H*',($F='F'x19).
"F0F3E0607879CC1E0F0F339F3FF399C666733333CCF87F99E6133999999E67CFFCCF3".
"219CC1CCC033E7E660198CCE4E66798303873CCE60F3387$F"#Don't you love Perl?
Alejo.
http://bachue.com/alejo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030528/a2ac7e3e/attachment.bin