Community
Participate
Working Groups
An Exception is thrown when trying to browse a remote resource using SFTP or Unix connections. "My Home" has no data and Root has "/" but browsing for children causes the exception to be thrown. Attached is a screen shot of what happens. The account I was using was disabled for SSH and so an error was being given but RSE simply threw an exception without any information instead of providing a reason for the exception.
Created attachment 96080 [details] screenshot
CQ:WIND00108151 We've had this report before, see bug 203502 comment 1 -- it happens on small embedded targets with Dropbear SSH Service for instance, since Dropbear does not provide sftp by default. See bug 213438 comment 1 for enabling sftp on dropbear. Anyways, we should improve the error message when sftp is not available. This might require introducing a new NLS String so I'm marking it M7. We'll also need to check if or how we can disable the Sftp subsystem but still keep the SSh Shell Subsystem active. They share the same connector service, so "disconnect" on only one of them seems impossible, making the problem nontrivial.
Not for M7
Bulk update of target milestone
Will need to look at this in 3.0.1
bulk update of target milestone
*** Bug 265881 has been marked as a duplicate of this bug. ***
Created attachment 127669 [details] Screenshot: proposed solution I've got a potential solution coded, where the error message is shown as a child of the node that user tries to expand in RSE. That way, we do not disconnect the Sftp subsystem but show the exception; if users continue to fiddle with the Sftp subsystem, more connect attempts will be made resulting in the same exception again. Still, the advantage of this approach is that the Shell and Terminal subsystems can remain connected (which was nontrivial since all SSH services share the same connectorService). I still need to think about if or how to log the exception. Usually, we'd say that this is a message shown to the user (with localized String), so we'd not want it logged. On the other hand, the actual exception backtrace is lost that way, making more investigations hard. I think that logging the exception or not should depend on a global logging level; but that may be hard to do in a generic way. Feedback about the proposed solution would be appreciated.
Martin, your proposal looks good from my perspective: as long as the end-user gets informed about the original cause of the communication error it would be consistent with any other clients of the (SSH) protocol. That means, the end-user is not required to try other means to connect to the same server to understand what's failing. Logging may be required when this proposed handling does not always show in UI as your screen capture shows, and yes it would likely depend on a global logging level. Thanks for your timely fix, Alex P.
One problem I've seen is that shell connections (e.g. when you do "ls") try contacting the sftp server a zillion times, thus performing slower than necessary. I think that we'll want to cache the fact that there won't ever be an sftp-server, in order to avoid trying again and again. That's why the fix isn't committed yet... By sure a cleaner solution would be if the SFTP Files Subsystem just doesn't get connected. But as it stands today, this re-uses the generic FileServiceSubSystem, which only asks the ConnectorService about "connected" status. I don't see an easy way to change this such that SSH subsystems can have independent "connected / available" status even if they share the same ConnectorService. Perhaps somebody has an idea?
I am only beginning to understand the inner layers of the subsystems, and I wonder if the issues I'm currently seeing are not related to your last comment. I have at least 2 cases where FileServiceSubSystem.list(...) fails during runtime (with another cryptic exception: RSEF1002: Operation failed. File system input or output error: Message reported from file system: <empty>). This never happens when I run through debug. I noticed a similar debug vs. runtime behavior divergence with RemoteFileUtility.getFileSubSystem(), but I found a work-around through using RSECorePlugin.waitForInitCompletion(). This again seemed to be a timing issue that makes me believe there are a few asynchronous aspects that are not well behaving or documented, and the exception handling gaps make it a rough experience. Should I open a different defect, or is there something obvious I'm missing ?
Ok, I think I've committed something that's good enough: [227135] Cryptic exception when sftp-server is missing Along the way, I cleaned up SystemOperationFailedException to provide better and more consistent reporting, and added Javadocs. The most important part of the fix is in SftpFileService.connect() where the error is now properly reported. One problem with the current behavior is that "My Home" behaves differently than any other path: when the user simply expands the "My Home" folder, an empty list is returned instead of the expected exception. That's partially an API problem (because getUserHome() doesn't throw any exceptions), and partially a problem in the FileServiceSubSystem sine an exception on connect() is not properly reported but silently swallowed. I'll leave it to Alex whether he wants to follow up on this or not with a separate bug -- some background information about the odd and IMO unsatisfying behavior of IFileService#getUserHome() is in bug 203490 and bug 204710.
