Community
Participate
Working Groups
By investigating bug 203490, I found that in the following case, IFileService.getUserHome() is called before the connection is connected, so the home directory is likely to return null: * Launch RSE, ensure no connection is connected * Expand an SSH connection * Select the "My Home" filter * Right-click > Refresh Refresh of the filter issues a getUserHome() call even if the connection is not yet connected -- this was the reason for the NPE in bug 203490. I'm not sure if fixing this issue is worth it, since returning null as result of getUserHome() seems to do the right thing. -----------Enter bugs above this line----------- TM 2.0.1 Testing installation : eclipse-SDK-3.3 (I20070625-1500), cdt-4.0.0, emf-2.3.0 RSE install : Download RSE-2.0.1RC1: RSE-SDK,examples,tests,discovery,terminal java.runtime : Sun 1.6.0_01-b06 os.name: : Windows XP 5.1, Service Pack 1 ------------------------------------------------ systemtype : Linux SSH-Only ------------------------------------------------
Created attachment 79223 [details] Patch updating IFileService Javadoc It turns out that it is hard for IFileService implementers what to return when they are asked for the home directory before they are connected. * They cannot auto-connect because credentials are not yet known * They cannot just dream up any default like "/" because it might change after being connected, so the results of expanding the "My Home" filter later might yield wrong results It turns out that returning null is the right thing, it will instruct the FileService to try again later. Returning null should be reserved for this case (there is a concept of a home directory, but it is not yet known). Clients which do not ever have a concept of a home directory should return the root directory or any other "useful" directory handle instead; the only precondition should be that this handle is "stable", so it always refers to the same remote object (which should exist, but does not necessarily need to -- resolving "My Home" would throw an error in that case). Attached patch updates Javadoc to capture these thoughts. It might be a good idea to come up with another well-known default (e.g. IHostFile with getAbsolutePath()=="") to indicate that an IFileService does not have any concept of a home directory; but that's reserved for the future. Essentially, returning null should ask the client to try again later. We could also reserve
Dave what do you think - is it normal to query the home directory while not yet connected? Does it seem right to explicitly allow returning null in the Javadoc?
Obviously we can't query the home dir while not connected. Allowing null to be returned seems like the right solution. At least the consumer of the call would not get an incorrect answer.
Updating Javadoc now seems right for 2.0.1 since we are just documenting what the code already did, so we are clarifying current behavior. Patch committed: [204710] Update Javadoc to mention that getUserHome() may return null IFileService 1.13
Updated summary to indicate what we did -- old value was: [refresh][files] File service queries home directory even if not connected
