Summary: | [ssh] Remote copy fails without notice if only sftp is enabled (but shell access is denied) | ||
---|---|---|---|
Product: | [Tools] Target Management | Reporter: | Glen A. <glen.84> |
Component: | RSE | Assignee: | dsdp.tm.rse-inbox <tm.rse-inbox> |
Status: | NEW --- | QA Contact: | Martin Oberhuber <mober.at+eclipse> |
Severity: | normal | ||
Priority: | P2 | CC: | mober.at+eclipse |
Version: | 3.0 | Keywords: | helpwanted |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 155189, 236334 |
Description
Glen A.
2008-08-18 07:56:48 EDT
Updated summary, previous value was: SFTP remote copy falls back to SSH – SSH access not enabled on account We should catch the exception and file a proper error message at the least. The error should tell users to manually download / upload the resources. A better solution would be to fall back to automatic download / upload like the EFS provider does. Note that the FTPService also provides an implementation of recursive-copy and recursive-delete, which could be used here. We should consider putting this algorithm into the FileServiceSubSystem such that it can be re-used if needed - a simpler implementation could just copy the algorithm into SftpFileService. In the FileServiceSubSystem, we could catch something like UnsupportedOperationException in case of copying / deleting a non-empty folder, in order to trigger the algorithm. In either case, the service should cache the fact that remote ssh shell is not available, and directly trigger the alternative algorithms if needed. In some cases, it could also be a user preference (see also bug 155189). We'd appreciate if somebody in the Community would want to take a look at this. Bulk update of target milestones to 3.2 Bulk moving 3.3 deferred items to 3.3.1 |