Bugzilla – Full Text Bug Listing
| Summary: | [cleanup] Protect against illegal API use of getRemoteFileObject() with relative path as name | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||
| Component: | RSE | Assignee: | Martin Oberhuber <mober.at+eclipse> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> | ||||
| Severity: | enhancement | ||||||
| Priority: | P3 | ||||||
| Version: | 3.0 | ||||||
| Target Milestone: | 3.0.1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 107395 [details]
Patch fixing the issue
Attached patch fixes the issue, and adds a Unittest to secure the fix.
Patch committed: [240704] Protect against illegal API use of getRemoteFileObject() with relative path as name |
I've seen some code today, which did IRemoteFile parent = ss.getRemoteFileObject("/folk/mober", mon); IRemoteFile child = ss.getRemoteFileObject(parent, "relative/path/foo", mon); doing this is very dangerous, since RSE eventually creates an IRemoteFile (and an IHostFile) with "relative/path/foo" as its name, and "parent" as its parent. As a result, API calls such as getParentRemoteFile() do not have the expected results. Errors due to such API mis-use can turn up much later, therefore the API should protect against this mis-use. API Docs already say that the "name" must be an "unqualified name" which means it must not have a separator in it. We should add an assertion and/or IllegalArgumentException to protect against such API mis-use.