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

Guillaume Nodet resolved SSHD-424.
----------------------------------
       Resolution: Fixed
    Fix Version/s: 1.0.0
         Assignee: Guillaume Nodet

https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=commitdiff;h=687e77122cdaf57d4c19a248e2d97a87f0ce6294

> Avoid inadvertent closure of the input stream used by ScpHelper#receiveFile
> ---------------------------------------------------------------------------
>
>                 Key: SSHD-424
>                 URL: https://issues.apache.org/jira/browse/SSHD-424
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 1.0.0, 0.14.0
>            Reporter: Goldstein Lyor
>            Assignee: Guillaume Nodet
>            Priority: Minor
>             Fix For: 1.0.0
>
>         Attachments: 
> 0027-SSHD-424-Avoid-inadvertent-closure-of-the-input-stre.patch
>
>
> The current code wraps the session _InputStream_ inside a _FilterInputStream_ 
> in order to limit the available data for read to the specified length. 
> However, the _FilterInputStream_ instance _close_ method is not overridden - 
> i.e., if the wrapper stream is closed, this will also close the session 
> stream, which would make it impossible to read the ACK (or other SCP 
> commands). Granted, that the current wrapper stream is not inside a 
> _try-with-resource_ block, so *theoretically* it's _close_ method should not 
> be called. However, there are good reasons to (a) override the _close_ method 
> and *explicitly* avoid closing the wrapped stream and (b) place the wrapped 
> stream inside a _try-with-resource_ block:
> * Good programming practices - if a data stream goes out of scope, make sure 
> it is closed.
> * Avoid a possible race condition between the garbage collector and our code. 
> When the garbage collector decides that the wrapper stream is no longer 
> required, it may also decide to close it. However, it may occur while we are 
> trying to read the ACK or be in the midst of processing another SCP command. 
> In such a scenario we would get an _IOException_ on an *unrelated* command.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to