Community
Participate
Working Groups
Created attachment 206997 [details] proposed patch for RSEConnectionManager to support missing query in URI The logic for RSEConnectionManager getConnection(URI uri) public IRemoteConnection getConnection(URI uri) { /* * See org.eclipse.rse.internal.efs.RSEFileSystem for definition */ String name = uri.getQuery(); if (name == null) { name = uri.getHost(); } return getConnection(name); } is flawed when the query is missing. The manager creates a hash based on alias-name which won't match the host name (creating a new RSE host and specifying the same name for host and connection results in the host name being upper-cased and the hash fails). The logic should instead iterate through the connections to find a connection with the same host name. I have provided a patch for master based on a simple iteration of the connections, looking for the first host match.
getConnection should not really use the host name at all. RSE's use of the host name in the URI makes it impossible to determine which connection to use, since multiple connections can point to the same host. In what situation does the URI get created without a query part? RSEFileManager#toURI() should always add it.
(In reply to comment #1) > getConnection should not really use the host name at all. RSE's use of the host > name in the URI makes it impossible to determine which connection to use, since > multiple connections can point to the same host. In what situation does the URI > get created without a query part? RSEFileManager#toURI() should always add it. If you resolve a URI, it seems to remove the query portion. In my particular instance, I had accidentally deleted it from the project URI in modifying the RSE location from the C Project wizard drop down to add the project name into the URI. I agree that multiple connections is problematic but if there is only one connection to the host (not atypical), is that not sufficient to use from the look-up and bail if there are multiple host finds? Regardless, the current fall-back logic in place cannot work.
Current remote support uses Jsch directly, so this is probably no longer required. Please reopen if this is not the case.
