Created attachment 1898 [details] Initial implementation of the fsync@openssh.com extension In some cases the delay between when a file has been transferred and when the operating system actually flushes data to disk may provide an opportunity for file loss or corruption. To address this, it would be useful to call fsync(2) after writing a file. The attached patch adds an fsync@openssh.com extension to sftp-server which can be used to request that fsync(2) be called. In addition, a -f option has been added to get/put and to the sftp command-line itself to request local or remote fsync(2) of the written file.
The diff looks good, I'll add this to the list for V_5_6
Created attachment 1905 [details] Correct return code from do_fsync() when server does not support the extension
We are freezing for the OpenSSH 5.6 release. Retargetting these bugs to the next release.
Retarget unclosed bugs from 5.7=>5.8
Created attachment 2065 [details] Updated patch vs -current
Retarget unresolved bugs/features to 6.0 release
Retarget unresolved bugs/features to 6.0 release (try again - bugzilla's "change several" isn't)
Retarget from 6.0 to 6.1
Retarget 6.0 => 6.1
Retarget uncompleted bugs from 6.1 => 6.2
Retarget bugs from 6.1 => 6.2
retarget to openssh-6.3
I just came across this proposed extension of sftp in OpenSSH, and it's something that we could really use in order to make qemu ssh block device safe: http://lists.nongnu.org/archive/html/qemu-devel/2013-04/msg01118.html
I have now added support to libssh2 to support this call, and also tested that it works (it does). http://www.libssh2.org/mail/libssh2-devel-archive-2013-04/0007.shtml http://www.libssh2.org/mail/libssh2-devel-archive-2013-04/0006.shtml
Retarget to openssh-6.4
Retarget 6.3 -> 6.4
Why does this keep getting delayed? Why not just add the patch? It's a simple & useful feature which would allow qemu to use OpenSSH.
Created attachment 2351 [details] Updated to -current Revised patch, with description of extension in the PROTOCOL file. Hopefully I'll be able to get it in this time. I wasn't able to convince everyone that it was worth the DoS risk before (many platforms implement fsync() by just calling the fs-wide sync() function which can trigger a lot of I/O), but now we have the request blacklist that can avoid this in cases where users can't be trusted.
small doco error in PROTOCOL 339 string "hardlink@openssh.com"
Committed - this will be in OpenSSH 6.4. Thanks!
Close all resolved bugs after 7.3p1 release