You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Joshua Hudson (JIRA)" <ji...@apache.org> on 2016/02/25 21:49:18 UTC

[jira] [Created] (SSHD-657) missing hardlink@openssh.com sftp extension

Joshua Hudson created SSHD-657:
----------------------------------

             Summary: missing hardlink@openssh.com sftp extension
                 Key: SSHD-657
                 URL: https://issues.apache.org/jira/browse/SSHD-657
             Project: MINA SSHD
          Issue Type: New Feature
    Affects Versions: 1.0.0, 0.14.0, 0.13.0, 0.12.0, 0.11.0, 1.2.0
            Reporter: Joshua Hudson


Due to the upload requirements of implementing a message protocol over sftp where truncated
messages aren't easily detected by the receiving system, the extension is required to avoid
data corruption. In particular, the operation permits us to upload to a scratch name to be
ignored by the pickup process, and then rename to a name that will pick up, while atomically
erroring if the pickup name already exists.

In particular, the only safe upload sequence is:

rm working.@tmp@
put working.@tmp@
do {
   ln working.@tmp@ serial.txt
   increment serial
} while (ln reported file exists)

The ln operation is hardlink@openssh.com. We cannot substitute a ren operation here because
ren is allowed to clobber an existing file. Even if your code checks for this, there is beneath
it a race condition because the rename() system call doesn't check, and we must be race condition
free.

Anyway, I didn't think there were any more sftp providers left standing that didn't implement
hardlink@openssh.com; turns out I was wrong. I whipped up a quick patch to the hosting provider
involved to demonstrate how easy this is to implement. The patch probably works, but I have no
place to try it. I'm fairly confident because I just implemented a client side version a few
months ago.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)