The "put -r" support in sftp(1) expects a directory with the same name as teh source directory to exist on the server prior to the upload. That is contrary to the behaviour of "scp -r" and is thus unexpected. It is also contrary to the behaviour of "get -r." sftp> cd test sftp> lcd /etc sftp> ls sftp> put -r sasl2 Uploading sasl2/ to /u1/imorgan/test/sasl2 Couldn't canonicalise: No such file or directory Unable to canonicalise path "/u1/imorgan/test/sasl2" sftp> sftp> mkdir sasl2 sftp> put -r sasl2 Uploading sasl2/ to /u1/imorgan/test/sasl2 sasl2/libvirt.conf 100% 1161 1.1KB/s 00:00 sasl2/smtpd.conf 100% 49 0.1KB/s 00:00 sasl2/Sendmail.conf 100% 25 0.0KB/s 00:00 sftp>
*** Bug 2230 has been marked as a duplicate of this bug. ***
"put -r" is completely broken and will not recurse sftp> put -r olds/* olds/ Uploading olds/2013/ to /nfs/bronfs/uwfs/dw00/d12/ammon0/olds/2013 Entering olds/2013/ Uploading olds/2014/ to /nfs/bronfs/uwfs/dw00/d12/ammon0/olds/2014 Entering olds/2014/ Uploading olds/2015/ to /nfs/bronfs/uwfs/dw00/d12/ammon0/olds/2015 Entering olds/2015/ Uploading olds/2016/ to /nfs/bronfs/uwfs/dw00/d12/ammon0/olds/2016 Entering olds/2016/ each of these directories has multiple entries but none were uploaded
Version information: $ apt-cache policy openssh-client openssh-client: Installed: 1:6.9p1-2ubuntu0.1 Candidate: 1:6.9p1-2ubuntu0.1 Version table: *** 1:6.9p1-2ubuntu0.1 0 500 http://us.archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ wily-security/main amd64 Packages 100 /var/lib/dpkg/status 1:6.9p1-2 0 500 http://us.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages I will also be reporting this on launchpad.net
Restore bug to correct state. This is a general, platform-independent issue that affects multiple versions of OpenSSH, including -current. It doesn't seem appropriate to me to alter this bug to imply that it is relevant to a specific release, operating system, or hardware. Feel free to add supporting attachments, proposed fixes, relevant comments on the issue, but please don't try to take over someone else's but. As to the claim of "completely non-functional" made in the egregious change to the summary, it would have been appropriate to have included some evidence of that as an attachment. In my experience, recursive upload works -- provided that the target directory exists.
Please forgive the various mistakes I made. In my defence, if the information on this page was not meant to be edited by the public then it should not be able to be edited by the public. I will not waste time with reasoning or justifications. In any case, the fact that "put -r /stuff/*" fails to recurse into sub-directories is evident by the terminal output I submitted in comment #2. If you have not experienced this then I suspect that the issue is separate: platform and/or version specific. In this case am I to understand that I should submit a separate bug report?