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

Thomas Wolf closed SSHD-1147.
-----------------------------
    Fix Version/s: 2.7.0
         Assignee: Thomas Wolf
       Resolution: Fixed

> SftpClient is not able to download file from proprietory SFTP servers (IBM) 
> with a one time download policy
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: SSHD-1147
>                 URL: https://issues.apache.org/jira/browse/SSHD-1147
>             Project: MINA SSHD
>          Issue Type: Wish
>    Affects Versions: 2.5.1
>            Reporter: Alex D
>            Assignee: Thomas Wolf
>            Priority: Major
>             Fix For: 2.7.0
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Some propretory SFTP servers support a so-called "one time download" policy 
> also known as Extractability Count.
> Current implementation of the input stream based read ofile operation 
> org.apache.sshd.client.subsystem.sftp.SftpClient::read(String path) uses 
> org.apache.sshd.client.subsystem.sftp.impl.SftpInputStreamAsync
> which performs 2 operations in its constructor:
> 1) Open remote file (SftpClient::open)
> 2) Calculate remote file size using file's handle obtained in 1)
> As a result the following error is produced on attempt to download a file 
> from IBMs SFTP:
> SFTP error (SSH_FX_FAILURE): The message [remote file path] is not 
> extractable!
> IBM specifically states that it's not their problem at all, and they are not 
> going to fix it.
> According to their flow described here:
> https://www.ibm.com/support/pages/node/1121475?lang=en
> "Any attempt from client to issue other SFTP operations like SSH_FXP_STAT 
> (reading attributes) makes server to validate extractability_count > 0.
> If found 0, download would be reported as "not extractable".
> Most likely it's possible to use SftpClient::openRemoteFileChannel and work 
> with the obtained FileChannel manually without any additional requests to 
> stat remote file size.
> Though it would be a cumbersome approach, as reading remote file in chunks 
> not knowing its size in this case will be far from optimal.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Reply via email to