[
https://issues.apache.org/jira/browse/VFS-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17085928#comment-17085928
]
Gary D. Gregory edited comment on VFS-630 at 4/17/20, 4:47 PM:
---------------------------------------------------------------
Definitively do not "rip it out", you'll want to add a toggle, see
{{org.apache.commons.vfs2.provider.sftp.SftpFileSystemConfigBuilder}} and the
{{DISABLE_DETECT_EXEC_CHANNEL}} option.
The preferred format is a PR on GitHub at
[https://github.com/apache/commons-vfs
|https://github.com/apache/commons-vfs]on top of git master.
was (Author: garydgregory):
Definitively do not "rip it out", you'll want to add a toggle, see
The preferred format is a PR on GitHub at
[https://github.com/apache/commons-vfs
|https://github.com/apache/commons-vfs]on top of git master. see
{{org.apache.commons.vfs2.provider.sftp.SftpFileSystemConfigBuilder}} and the
{{DISABLE_DETECT_EXEC_CHANNEL}} option.
> 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
(v8.3.4#803005)
