commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "L (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (VFS-630) Sftp code assumes that exec channels are available and *nix server
Date Wed, 05 Apr 2017 07:42:41 GMT

    [ https://issues.apache.org/jira/browse/VFS-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956456#comment-15956456
] 

L commented on VFS-630:
-----------------------

It is a duplicate of VFS-590.

> Sftp code assumes that exec channels are available and *nix server
> ------------------------------------------------------------------
>
>                 Key: VFS-630
>                 URL: https://issues.apache.org/jira/browse/VFS-630
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.1
>         Environment: Any client running VFS 2.1/JSch 1.51 and later using remote sftp
server that's locked down or not *nix based.
>            Reporter: Will Wood
>            Priority: Minor
>
> In working with VFS using SFTP there's an assumption in the code that creates a problem
if the remote server is locked down or it's not *nix based.  I hit this when working with
a server that had exec commands disabled and attempting to do a moveTo command on a remote
file object renaming it to the same server as a remote file object.  At one point the VFS
code attempts to execute an "id -G" command on a JSch "exec" channel. Since the remote server
disallows the exec command the subsequent read from the input stream blocks until the O/S
default socket timeout occurs, it basically hangs.
> I tested this same scenario against a Linux server, it worked fine.  I also tested a
Windows server which doesn't have an id command, it failed.
> Since JSch deals with this natively, I would recommend getting rid of the exec commands
altogether and letting the client deal with those issues outside of the framework, i.e., moveTo
in this case doesn't need to worry about permissions but rather throws the underlying exceptions
from JSch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message