[
https://issues.apache.org/jira/browse/SSHD-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14330308#comment-14330308
]
David Evans commented on SSHD-108:
----------------------------------
This issue has been here for several years with no updates, and I've hit the
same problem, so here's a possible solution (requires a small API-breaking
change to the library):
Clients seem to reliably send SSH_FXP_CLOSE after they have uploaded a file,
but if the upload is aborted, they will instead reset the connection. However
MINA SSHD handles both of these scenarios by closing the stream and calling
handleClose on the file.
The change would be to provide a new interface method in SshFile (perhaps
"handleClientClose"). With this, handleClose continues to be called in all
cases, while handleClientClose is called - before handleClose - only if
SSH_FXP_CLOSE was the trigger (I also considered a boolean parameter but a new
method seems cleaner).
Specifically, this line would be the only one which triggers both
handleClientClose and handleClose:
https://github.com/apache/mina-sshd/blob/sshd-0.13.0/sshd-core/src/main/java/org/apache/sshd/server/sftp/SftpSubsystem.java#L474
(SftpSubsystem.Handle would also need to be extended to be aware of which close
type is required)
There *may* also need to be a change to make this work nicely with SCP.
Currently the SCP path doesn't call handleClose at all, but perhaps it should?
(since it gets called from exception paths already it seems like it is intended
as a general clean-up method when finished with a file).
https://github.com/apache/mina-sshd/blob/sshd-0.13.0/sshd-core/src/main/java/org/apache/sshd/common/scp/ScpHelper.java#L187
An alternative which would not require an API-breaking change (and is slightly
more open to future variants, e.g. pause detection) would be to provide an
interface which could be optionally implemented by the OutputStream returned by
createOutputStream. This would have just 1 extra method (perhaps
"handleSuccess"), which would be called in the same scenarios as described for
handleClientClose above. The down-side to this approach is discoverability; the
best way to explain it is in the JavaDoc of createOutputStream, but any user
missing that would likely never know the functionality exists.
I'm aware that SshFile is shared between server and client logic, and I'm only
thinking about this from a server perspective, so it might be nice to get the
client-side perspective of this API change (specifically, is there any similar
client event where it would make sense to share this new method).
It may also be worth noting that an abort causes java.io.IOException:
Connection reset by peer, whereas pausing causes java.io.IOException: Broken
pipe (at least with FileZilla as the client). While I don't need to access that
information for my needs, a future user might want to distinguish between those
two events as well. I couldn't figure out a way to expose that though, since
both seem to be swallowed and translated into a close connection command.
> Add upload monitoring to sftp and scp
> -------------------------------------
>
> Key: SSHD-108
> URL: https://issues.apache.org/jira/browse/SSHD-108
> Project: MINA SSHD
> Issue Type: Improvement
> Affects Versions: 0.5.0
> Reporter: Richard Evans
> Priority: Minor
>
> We have sshd integrated into our application and sftp is working fine. One
> of the requirements is to initiate some action when a file upload it
> complete. I have made this work by implementing handleClose in my SshFile
> implementation and performing the action if createOutputStream had been
> called previously. This seems a bit ugly though; it might be nicer if there
> was some plug in mechanism to monitor file transfers.
> Ideally the monitor would be able to distinguish between a successful upload
> and a cancelled one (via ctrl-c at the client), but a quick perusal of the
> sftp stuff seems to inidicate that this is not possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
