Okay, so my scp:ing of a large file over an slow international link just died with more than half done.
After some googling I found this bug as well as some other things interesting to scp resuming. A thread that does not mention anything new, but that might be useful for others encountering this report while googling. http://lists.debian.org/debian-user/2004/09/msg03529.html Here's another solution than patching: http://www.xs4all.nl/~ejtaal/scripts-showcase/ About patching upstream, they state in their FAQ that they will not accept additions to scp. However if implementing it in sftp it might have a chance to get in. http://www.openssh.org/faq.html#2.10 The draft standard they mention is nowhere to be found. I won't give any strong opinions on how I think the functionality should be - because I am not sure. On one side I feel that copying a file is so central to scp that resuming operation on fail should exist as a core feature, but on the other bloated software is not what we want. Perhaps it would be possible to include a smart resume-scp script in the package? Depending on rsync and expecting users to learn its syntax is not the ideal solution if you ask me. -- /Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
