Community
Participate
Working Groups
Our company has a number of servers with multiple sites on each one. These sites are separated in the httpd vhost file. To get to the FTP of these sites, I connect to a single IP. The username of each site is different. If I want to compare two files on this server on two different ftp's but with exactly the same base path, RSE opens only one of them, and activates the other one from the cache. Possible solution: - create local file structure by ftp location name in stead of domain name - set ftp location name as unique. I have tried this with RSE 3.0 With regards, Mark Roeling Exed Internet The Netherlands
This is actually a duplicate of bug 193858, which requested different cache paths for connections to the same host but with a different port. There is a workaround for the issue (use alternative variants of specifying the host name, e.g. 1.2.3.4 -- connection 1 myhost -- connection 2 myhost.foo.bar -- connection 3 For a better fix, ISV's can contribute an extension to the mountPathMappers extension point, see bug 195285 and the documentation on http://dsdp.eclipse.org/help/latest/index.jsp?topic=/org.eclipse.rse.doc.isv/reference/extension-points/org_eclipse_rse_ui_mountPathMappers.html Bug 152992 is also related (proper cache pathes for tunnelling). The real dilemma in this specific case is, that there are cases where different logins to the same host *should* map to the same temp files location in order to allow re-use and reduced data transfer. In most cases, different user's logins will actually lead to different remote absolute pathes even if on the same host, so this is not typically an issue. I'm going to keep this bug open for some discussion, whether we need some common UI to tweak the mountPathMapper. What do you think? Could you write a mountPathMapper extension yourself? Does the workaround work for you? Note that you can create a local "hosts" file with as many host aliases as you want to trick RSE. I'd propose reducing severity to "normal" since there is a workaround, ok? Changing the summary, previous value was: Multiple FTP connections to single server, by IP
Here are two more ideas for this: (1) We could ship a sample extension of the mountPathMappers extension point, which takes the aliasName of the connection into account for mapping. That way, ISV's can see how to do it. (2) We could add a checkbox on the file subsystem property page "Share cached files with other connections if possible". If enabled, the mountPathMapper would map as it does today. If disabled, the aliasName of the connection would be taken into account, in order to create a unique mapping for this particular connection. Adding DaveM for comments, what do you think? - Tentatively Considering for 3.1 since this has come up repeatedly now.
Note that these suggestions would also fix bug 152992. See also http://dsdp.eclipse.org/help/latest/topic/org.eclipse.rse.doc.isv/reference/api/org/eclipse/rse/files/ui/resources/ISystemMountPathMapper.html
(In reply to comment #2) > Here are two more ideas for this: > (1) We could ship a sample extension of the mountPathMappers extension point, > which takes the aliasName of the connection into account for mapping. That > way, ISV's can see how to do it. > (2) We could add a checkbox on the file subsystem property page "Share cached > files with other connections if possible". If enabled, the mountPathMapper > would map as it does today. If disabled, the aliasName of the connection > would be taken into account, in order to create a unique mapping for this > particular connection. > Adding DaveM for comments, what do you think? - Tentatively Considering for 3.1 > since this has come up repeatedly now. I like the ideas. For (2), would this be more suitable as something on a property page or a preference page. Because more than one connection and file subsystem is involved, I'm inclined to think of this as a preference.
Eclipse 3.3.2 and RSE 3.0, same problem : Two connection with two different users, to the same FTP server. If I open /my/dir/myfile.php on the connection #1, and then the same file on the connection #2, the cached version of the #1 file is showed instead of the #2 Little workaround for those who can't wait this bug to be fixed : on the #1 connection, use the DNS to the server ( ie : my.dns.com) and for the #2 connection, use the ip adress ( ie : 10.15.12.25 ) of the same ftp server. So the problem comes from the name of the server, wich is the unique key in RSE's cache instead of a unique key on "server + user"
ok sorry guys, did'nt saw your conversation before posting my message keep up the good work
Created attachment 122280 [details] patch with share cached files preference With this patch, RSE provides a preference for sharing cached files between connections to the same host. By default the preference is set to true (providing the original behaviour). When the user changes it to false, the DefaultMountPathMapper honours the preference by prepending the host name alias (connection name) to the path. Note that contributed mount path mappers would also need to honour the preference in their own ways.
Martin, could take a look at the patch and provide feedback? One thing I wonder is whether the host alias is good enough of a qualifier since we may need to deal with the case where there are multiple file subsystems under a single connection. That suggests that a subsystem port might be a better choice, however, I don't know how we can be sure that those ports are necessarily used or unique. Perhaps we can use a combination of the host alias and the subsystem name or id.
Comment on attachment 122280 [details] patch with share cached files preference Patch looks good to me, comments: * If we pick the aliasName as a prefix (which I think we should!), then changing connection properties after having some cached files is always an issue. For instance, changing the FTP port or the SSH port may completely change the file system; same for changing the user name, or the service ID underneath the connection. I'm not exactly sure how to address it, but one option would be to register an event handler for such connection property changes, such that a dialog gets displays that tells users like "You changed connection properties, cached files may be invalid. Do you want to delete the remote files cache for this connection?" * Similar, for renaming a connection, a dialog could say "You have cached files for this connection, ..." - but we could leave this out for a potential future enhancement * I like the prefix of aliasName + subsystemID * We should make sure that our "aliasName" prefix cannot ever conflict with the old defaultMountPathMapper mechanism, which I think was the hostname first; can we prefix the path with something that would be an invalid hostname like e.g. just ".alias/" * As another additional usability enhancement, when a new connection gets created that has an IFileServiceSubSystem, and we detect that another host with files already exists, we could show a dialog pointing users to the Preference page (with a "do not show again" checkbox).
(In reply to comment #9) > (From update of attachment 122280 [details]) > Patch looks good to me, comments: > > * If we pick the aliasName as a prefix (which I think we should!), then > changing connection properties after having some cached files is always an > issue. For instance, changing the FTP port or the SSH port may completely > change the file system; same for changing the user name, or the service ID > underneath the connection. I'm not exactly sure how to address it, but one > option would be to register an event handler for such connection property > changes, such that a dialog gets displays that tells users like "You changed > connection properties, cached files may be invalid. Do you want to delete the > remote files cache for this connection?" > > * Similar, for renaming a connection, a dialog could say "You have cached files > for this connection, ..." - but we could leave this out for a potential future > enhancement > > * I like the prefix of aliasName + subsystemID > > * We should make sure that our "aliasName" prefix cannot ever conflict with the > old defaultMountPathMapper mechanism, which I think was the hostname first; can > we prefix the path with something that would be an invalid hostname like e.g. > just ".alias/" > > * As another additional usability enhancement, when a new connection gets > created that has an IFileServiceSubSystem, and we detect that another host with > files already exists, we could show a dialog pointing users to the Preference > page (with a "do not show again" checkbox). > I've changed the prefix to be <aliasName>.<subsystem configuration id>. The path is still stored under the hostname. For example, if the hostname is "myhost" and the alias is "myalias", when the dstore file service is used, the file /home/dmcknigh/abc.txt is stored as the following: .../RemoteSystemsTempFiles/myhost/myalias.dstore.files/home/dmcknigh/abc.txt I've committed these changes to cvs. As for the additional issues: detecting renamed aliases, and detecting another host with file that already exist, I'd prefer to handle those in a different defect.
Since the change is committed I'm closing the bug.
I'm concerned about the way the Preference is initialized to its default. For me, it looks like the default will be "false" until the UI Preference Page gets opened at least once. This results in unpredictable behavior and is problematic. I think that we need to do the same as we have already done in DStoreConnectorService.initializeDefaultPreferences() and get rid of the invalid default-init code in UniversalPreferencePage. If there is no time to do this "correct" solution, then at the very least the default init code should be moved into UniversalPreferencePage.initDefaults(store); On another note, we should be discussing what we think the right default value is. Is there really a need to preserve the 3.0 behavior for backward compatibility (with default value "true"), or could we move to a default "false" which is probably less optimized but results in well-defined understandable behavior for the user? -- In my opinion, default preferences should always be the "safe bet" and users should be able to tune their settings for better performance by changing the preference. Reopening the bug for consideration.
(In reply to comment #12) > I'm concerned about the way the Preference is initialized to its default. For > me, it looks like the default will be "false" until the UI Preference Page gets > opened at least once. This results in unpredictable behavior and is > problematic. > > I think that we need to do the same as we have already done in > DStoreConnectorService.initializeDefaultPreferences() > > and get rid of the invalid default-init code in UniversalPreferencePage. If > there is no time to do this "correct" solution, then at the very least the > default init code should be moved into > UniversalPreferencePage.initDefaults(store); > Right now the preference gets initialized via the rse.files.ui Activator in: public void initializeDefaultRSEPreferences() { //FIXME This should really be migrated into a Preferences Initializer Extension //in order to avoid unnecessary plugin activation IPreferenceStore store = RSEUIPlugin.getDefault().getPreferenceStore(); SystemCachePreferencePage.initDefaults(store); UniversalPreferencePage.initDefaults(store); } > On another note, we should be discussing what we think the right default value > is. Is there really a need to preserve the 3.0 behavior for backward > compatibility (with default value "true"), or could we move to a default > "false" which is probably less optimized but results in well-defined > understandable behavior for the user? -- In my opinion, default preferences > should always be the "safe bet" and users should be able to tune their settings > for better performance by changing the preference. > > Reopening the bug for consideration. > Regarding what the default should be, I'm open to prevailing opinions. Personally, I like sharing files between connections but then my usage may not mirror that of others.
(In reply to comment #13) > Right now the preference gets initialized via the rse.files.ui Activator in: > public void initializeDefaultRSEPreferences() As you know from bug 245918, this method doesn't allow setting default prefs via plugin_customization.ini, which might be particularly important especially in this case. We know how to fix this, so why not fix it? Moreover, the duplicate initialization in UniversalPreferencePage#createFieldEditors() is unnecessary and misleading. > Regarding what the default should be, I'm open to prevailing opinions. Let's discuss this on our next meeting. My opinion is that the default should be "safe" for everyone even if it's not optimal in terms of performance. Which would mean "false" in this case.
Created attachment 124555 [details] patch changing preference initialization Martin, is this the sort of change you had in mind for preference initialization?
I'd prefer seeing the default init code in the Activator like in the org.eclipse.rse.connectorservice.dstore plugin. By having the default init in the prefs page, you load the prefs page class whenever the bundle starts, thereby dragging in a whole lot of UI related stuff that's not needed at this point.
Created attachment 124580 [details] updated patch for preference initialization Here's the patch moving the defaults to the Activator.
Ok, much better :-) When querying a default value in the UniversalPreferencePage, you don't need the ScopedPreferenceStore since you already know you want the DefaultScope. Better just do new DefaultScope().getNode(RSEUIPlugin.getDefault()...) the API is slightly different but you'll get it. I did not understand what you do with the initialArchiveType, archiveTypeCombo, and the new initControls() method.
Created attachment 124582 [details] another update for pref init
(In reply to comment #18) > Ok, much better :-) > > When querying a default value in the UniversalPreferencePage, you don't need > the ScopedPreferenceStore since you already know you want the DefaultScope. > Better just do > > new DefaultScope().getNode(RSEUIPlugin.getDefault()...) > > the API is slightly different but you'll get it. > > I did not understand what you do with the initialArchiveType, archiveTypeCombo, > and the new initControls() method. > I've updated the patch again. The initControls() method is used as a single place to set the preference controls to the preference values. I thought this would help make this page more consistent since other pages have this method.
There are still two occurrances of ScopedPreferenceStore which you could get rid of same as before, or by using RSEUIPlugin.getPreferenceStore(). Copyright-to-date should be 2009. Other than that, I'm good with it.
(In reply to comment #21) > There are still two occurrances of ScopedPreferenceStore which you could get > rid of same as before, or by using RSEUIPlugin.getPreferenceStore(). > Copyright-to-date should be 2009. Other than that, I'm good with it. > I've made the updates and committed the change to cvs.
*** Bug 152992 has been marked as a duplicate of this bug. ***
*** Bug 193858 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > > On another note, we should be discussing what we think the right default > > value is. In my opinion, default preferences should always be the > > "safe bet" and users should be able to tune their settings for better > > performance by changing the preference. > > Regarding what the default should be, I'm open to prevailing opinions. > Personally, I like sharing files between connections but then my usage may not > mirror that of others. Did we come to a conclusion on this yet? - As said before, I'm in favor of having the default value OFF, i.e. not sharing files in the cache between connections. May I file a new bug for this?
