[
https://issues.apache.org/jira/browse/SSHD-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308543#comment-17308543
]
Thomas Wolf commented on SSHD-1147:
-----------------------------------
Patch is merged to master. Would still be useful to know if it indeed solves
the problem with these one-time-download files.
> 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: [email protected]
For additional commands, e-mail: [email protected]
