[
https://issues.apache.org/jira/browse/SSHD-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16257155#comment-16257155
]
Goldstein Lyor commented on SSHD-785:
-------------------------------------
{quote}it's such a complicated protocol for file transfer{quote} - indeed it is
{quote}writing your own FilesystemProvider + Filesystem looks like it would
have been a pretty significant task as well{quote} - true, but there may be
"middle road" - if you look at the {{SftpSubsystem}} class then it actually
breaks down the protocol for you, so IMO perhaps you could subclass it and then
not have to deal with the protocol itself on one hand and also avoid writing a
full-blown {{FilesystemProvider}}:
{code:java}
public class MySpecialSftpImpl extends SftpSubsystem {
....
@Override
protected doOpenFile(String name, ...) {
...
}
@Override
protected doReadFromFile(String name, ...) {
...
}
...etc...
}
SshServer sshd = SshServer.setupServer();
sshd.setSubsystemFactory(new SftpSubsystemFactory() {
protected SftpSubsystem create() {
return new MySftpSubsystem();
}
});
{code}
> ChannelPipedInputStream attempts to read from client even for 0-byte reads.
> ---------------------------------------------------------------------------
>
> Key: SSHD-785
> URL: https://issues.apache.org/jira/browse/SSHD-785
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: Antti S. Lankila
> Assignee: Goldstein Lyor
> Priority: Minor
> Fix For: 1.7.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I ran into interoperability issue between my own implementation of SFTP
> protocol (don't even ask) and JSch. The interaction between the client and
> server hangs on JSch attempting to issue REALPATH command for the empty
> string. This is method called getHome(), and it is used to handle resolving
> relative paths on the client side. The specifics why it does this are not
> important; the bug I ran into affects the situations where any ssh command
> packet contains the empty string.
> Using the REALPATH "" as example, the data for this command is just 4 zero
> bytes (length of string as 32-bit integer), and no string data.
> My code attempted to create the 0-byte string based on the length value, and
> basically executed this:
> byte[] buffer = new byte[0];
> in.read(buffer);
> The javadocs for InputStream says that if the length fo the passed byte[]
> buffer is 0, then the implementation just returns 0 and doesn't attempt to
> read anything. Unfortunately, ChannelPipedInputStream has its own
> implementation of read(byte[], int, int), and seems to attempt to read
> something from client before not actually using the data and returning 0.
> Client and server deadlock here: client waits for server reply, server waits
> for more data from client. Eventually, JSch timeouts, and closes the
> connection. What happens is that this 0 byte read then succeeds, server
> attempts to write back the FX_NAME response, but client has already closed
> connection, and the server gets an exception. In my case, this takes about 8
> minutes to happen, which corresponds to some default timeout in JSch.
> The fix would be to detect the attempt to read 0 bytes in
> ChannelPipedInputStream and just return early, similar to how
> java.io.InputStream does read(byte[], int, int). This bug should be fixed
> because this would align CPIS's implementation with the documentation and
> general behavior of java's InputStreams.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
