was initialized. This fixes a potential uninitialized use of 'limits' in
sftp_init() if sftp_get_limits() returned early because of an unexpected
message type.
ok djm@
OpenBSD-Commit-ID: 1c177d7c3becc1d71bc8763eecf61873a1d3884c
OpenSSH and it shows - the function names are terrible.
Rename do_blah() to sftp_blah() to make them less so.
Completely mechanical except for sftp_stat() and sftp_lstat() which
change from returning a pointer to a static variable (error-prone) to
taking a pointer to a caller-provided receiver.
OpenBSD-Commit-ID: eb54d6a72d0bbba4d623e2175cf5cc4c75dc2ba4
directories that contain symlinks to other directories. In scp mode, the
links would be followed, but in SFTP mode they were not. bz3611, ok dtucker@
OpenBSD-Commit-ID: 9760fda668eaa94a992250d7670dfbc62a45197c
requests.
sftp/scp will ftruncate the destination file after a transfer completes,
to deal with the case where a longer destination file already existed.
We tracked the highest contiguous block transferred to deal with this
case, but our naive tracking doesn't deal with servers that reorder
requests - a misfeature strictly permitted by the protocol but seldom
implemented.
Adjust the logic to ftruncate() at the highest absolute block received
when the transfer is successful. feedback deraadt@ ok markus@
prompted by https://github.com/openssh/openssh-portable/commit/9b733#commitcomment-110679778
OpenBSD-Commit-ID: 4af7fac75958ad8507b4fea58706f3ff0cfddb1b
make_absolute_pwd_glob work in the same way as make_absolute: you
pass it a dynamically allocated string and it either returns it, or
frees it and allocates a new one. Patch from emaste at freebsd.org and
https://reviews.freebsd.org/D37253 ok djm@
OpenBSD-Commit-ID: 85f7404e9d47fd28b222fbc412678f3361d2dffc
control over some SFTP protocol knobs: the copy buffer length and
the number of inflight requests, both of which are used during
upload/download.
Previously these could be controlled in sftp(1) using the -b/-R options.
This makes them available in both SFTP protocol clients using the same
option character sequence.
ok dtucker@
OpenBSD-Commit-ID: 27502bffc589776f5da1f31df8cb51abe9a15f1c
all cases, not just at the start of a transfer. This could cause overwrites
of larger files to leave junk at the end. Spotted by tb@
OpenBSD-Commit-ID: b189f19cd68119548c8e24e39c79f61e115bf92c
early
previous behavious of unconditionally truncating the destination file
would cause "scp ~/foo localhost:" and "scp localhost:foo ~/" to
delete all the contents of their destination.
spotted by solene@ sthen@, also bz3431; ok dtucker@
OpenBSD-Commit-ID: ca39fdd39e0ec1466b9666f15cbcfddea6aaa179
copying of files. Useful for this task and for testing the copy-data
extension. Patch from Mike Frysinger; ok dtucker@
OpenBSD-Commit-ID: 1bb1b950af0d49f0d5425b1f267e197aa1b57444
failures; provides better experience for scp in sftp mode, where ~user paths
are more likely to be used; spotted jsg, feedback jsg & deraadt ok jsg &
markus
OpenBSD-Commit-ID: fc610ce00ca0cdc2ecdabbd49ce7cb82033f905f
O_CREAT, the 3rd (variadic) mode_t parameter is irrelevant. Many developers
in the past have passed mode_t (0, 044, 0644, or such), which might lead
future people to copy this broken idiom, and perhaps even believe this
parameter has some meaning or implication or application. Delete them all.
This comes out of a conversation where tb@ noticed that a strange (but
intentional) pledge behaviour is to always knock-out high-bits from mode_t on
a number of system calls as a safety factor, and his bewilderment that this
appeared to be happening against valid modes (at least visually), but no
sorry, they are all irrelevant junk. They could all be 0xdeafbeef. ok
millert
OpenBSD-Commit-ID: 503d11633497115688c0c6952686524f01f53121
The subsequent call to stat_to_attrib clears the struct as its first step
anyway. From pmeinhardt via github PR#220, ok djm@
OpenBSD-Commit-ID: f5234fc6d7425b607e179acb3383f21716f3029e
~-prefixed paths, in particular ~user ones. Allows scp in sftp mode to accept
these paths, like scp in rcp mode does.
prompted by and much discussion deraadt@
ok markus@
OpenBSD-Commit-ID: 7d794def9e4de348e1e777f6030fc9bafdfff392
more useful with long paths (that may truncate) and better matches
traditional scp behaviour; spotted by naddy@ ok deraadt@
OpenBSD-Commit-ID: 26b544d0074f03ebb8a3ebce42317d8d7ee291a3
tracking expected status replies from the server to what do_download() was
using.
Refactor it to use the same structure and factor out some common
code into helper functions.
OpenBSD-Commit-ID: 0c167df8ab6df4a5292c32421922b0cf379e9054
scp(1) by suppressing "Retrieving [path]" lines that were emitted to support
the interactive sftp(1) client. ok markus@
OpenBSD-Commit-ID: 06be293df5f156a18f366079be2f33fa68001acc
downloading from one SFTP server while simultaneously uploading to another.
feedback & ok markus@
OpenBSD-Commit-ID: 3982878e29d8df0fa4ddc502f5ff6126ac714235
limits@openssh.com extension but fails when the client tries to invoke it.
Reported by Hector Martin via bz3318
OpenBSD-Commit-ID: bd9d1839c41811616ede4da467e25746fcd9b967
client select good limits based on what the server supports. Split the
download and upload buffer sizes to allow them to be chosen independently.
In practice (and assuming upgraded sftp/sftp-server at each end), this
increases the download buffer 32->64KiB and the upload buffer
32->255KiB.
Patches from Mike Frysinger; ok dtucker@
OpenBSD-Commit-ID: ebd61c80d85b951b794164acc4b2f2fd8e88606c
read-only directory, ensure that the directory is created with write and
execute permissions in the interim so that we can actually complete the
transfer, then set the directory permission as the final step. (The execute
bit is only likely to be an issue with a non-POSIX server). bz#3222, ok djm@
OpenBSD-Commit-ID: a82606212f2796e31f0e1af94a63355a7ad5d903
one more concurrent request that desired. This prevented using sftp(1) in
unpipelined request/response mode, which is useful when debugging. Patch from
Stephen Goetze in bz#3054
OpenBSD-Commit-ID: 41b394ebe57037dbc43bdd0eef21ff0511191f28
end of each transfer. Fixes the problem recently introduces where very quick
transfers do not display the progressmeter at all. Spotted by naddy@
OpenBSD-Commit-ID: 68dc46c259e8fdd4f5db3ec2a130f8e4590a7a9a
the progressmeter formatting outside of signal handler context and have the
atomicio callback called for EINTR too. bz#2434 with contributions from djm
and jjelen at redhat.com, ok djm@
OpenBSD-Commit-ID: 1af61c1f70e4f3bd8ab140b9f1fa699481db57d8
request they do not follow symlinks. Requires recently-committed
lsetstat@openssh.com extension on the server side.
ok markus@ dtucker@
OpenBSD-Commit-ID: f93bb3f6f7eb2fb7ef1e59126e72714f1626d604
download and fsync). These should return -1 on error, not a sftp status code.
patch from Petr Cerny in bz#2871
OpenBSD-Commit-ID: 651aa0220ad23c9167d9297a436162d741f97a09
