[
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)
