[
https://issues.apache.org/jira/browse/VFS-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17085417#comment-17085417
]
Kevin Hollenshead commented on VFS-630:
---------------------------------------
I'd be happy to try and create a patch but I'd like some thoughts from someone
in the know who can suggest a way to provide a toggle or default for this
behavior. It seemed to me to be less intrusive to leave the existing code and
skip it when you want to rather than rip it out. Also, what is the preferred
patch format? Standard *nix diff?
> 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)
