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

["Joshua Hudson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SSHD-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Hudson updated SSHD-657:
-------------------------------
    Attachment: mina_sshd.diff

draft quality patch

> 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: 0.11.0, 0.12.0, 0.13.0, 0.14.0, 1.0.0, 1.2.0
>            Reporter: Joshua Hudson
>              Labels: easyfix, features, newbie, patch
>         Attachments: mina_sshd.diff
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> 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)