Community
Participate
Working Groups
N20110810-2000 java version "1.7.0" Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode) I have two workspaces. In one workspace all works good but in the other workspace I get the error below logged many times (fills the log). The Secure Storage settings look the same in both workspaces. Note that I switch between 32- and 64-bit often. I also verified that org.eclipse.equinox.security.win32.x86_64_1.0.0.N20110810-2000.jar is there. Also, I don't get any dialog in the UI. !ENTRY org.eclipse.team.cvs.core 4 0 2011-08-18 15:34:32.552 !MESSAGE Unable to locate secure storage module (org.eclipse.equinox.security.windowspasswordprovider). !STACK 0 org.eclipse.equinox.security.storage.StorageException: Unable to locate secure storage module (org.eclipse.equinox.security.windowspasswordprovider). at org.eclipse.equinox.internal.security.storage.PasswordProviderSelector.findStorageModule(PasswordProviderSelector.java:190) at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getModulePassword(SecurePreferencesRoot.java:231) at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getPassword(SecurePreferencesRoot.java:224) at org.eclipse.equinox.internal.security.storage.SecurePreferences.get(SecurePreferences.java:262) at org.eclipse.equinox.internal.security.storage.SecurePreferencesWrapper.get(SecurePreferencesWrapper.java:106) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.retrievePassword(CVSRepositoryLocation.java:954) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.openConnection(CVSRepositoryLocation.java:798) at org.eclipse.team.internal.ccvs.core.client.Session.open(Session.java:159) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolderTreeBuilder.fetchDelta(RemoteFolderTreeBuilder.java:187) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolderTreeBuilder.buildTree(RemoteFolderTreeBuilder.java:155) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolderTreeBuilder.buildRemoteTree(RemoteFolderTreeBuilder.java:138) at org.eclipse.team.internal.ccvs.core.resources.CVSWorkspaceRoot.getRemoteTree(CVSWorkspaceRoot.java:178) at org.eclipse.team.internal.ccvs.core.syncinfo.CVSResourceVariantTree.fetchVariant(CVSResourceVariantTree.java:78) at org.eclipse.team.core.variants.AbstractResourceVariantTree.refresh(AbstractResourceVariantTree.java:84) at org.eclipse.team.internal.ccvs.core.syncinfo.CVSResourceVariantTree.refresh(CVSResourceVariantTree.java:334) at org.eclipse.team.core.variants.AbstractResourceVariantTree.refresh(AbstractResourceVariantTree.java:54) at org.eclipse.team.core.variants.ResourceVariantTreeSubscriber.refresh(ResourceVariantTreeSubscriber.java:162) at org.eclipse.team.core.variants.ResourceVariantTreeSubscriber.refresh(ResourceVariantTreeSubscriber.java:126) at org.eclipse.team.internal.ui.synchronize.RefreshSubscriberParticipantJob.doRefresh(RefreshSubscriberParticipantJob.java:116) at org.eclipse.team.internal.ui.synchronize.RefreshParticipantJob.run(RefreshParticipantJob.java:309) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
(In reply to comment #0) > The Secure Storage settings look the same in both workspaces. Note that I > switch between 32- and 64-bit often. That is probably the key issue. If the data was encrypted with a password provider A, only password provider A can decrypt the data. If you have stored CVS password in one session using 32-bit stack, then the 32-bit OS integration module was used to encrypt it. Now in the next run if you use 64-bit stack, the 32-bit integration module is not available and there is no way to decrypt stored data. The workaround would be to use different secure storage locations ("-eclipse.keyring <file path>" runtime option) for 32-bit and 64-bit stack.
I start with -keyring c:\eclipse\.keyring So, what you are saying is that everyone switching from 32-bit to 64-bit on the same machine, is doomed? Note that there is no information in the UI level at all. What am I supposed to do as a user?
Couldn't we ship both providers (in 32-bit and 64-bit download)?
(In reply to comment #3) > Couldn't we ship both providers (in 32-bit and 64-bit download)? They rely on JNI DLLs which are specific for 32-bit OS and 64-bit OS and can only be used in respective stack. (In reply to comment #2) > I start with > -keyring c:\eclipse\.keyring > That's "old" keyring (pre-3.5? or 3.4? not sure). The "-eclipse.keyring" is for the current implementation.
(In reply to comment #4) > (In reply to comment #3) > > Couldn't we ship both providers (in 32-bit and 64-bit download)? > > They rely on JNI DLLs which are specific for 32-bit OS and 64-bit OS and can > only be used in respective stack. Maybe you misunderstood me. The workspace was created on my 64-bit machine, but for testing purposes I sometimes use the 32-bit Eclipse version and sometimes the 64-bit one (along with the corresponding JRE). Given they both work fine on my machine with new and separate workspaces I don't see why Eclipse should not be able to read/write the same store with both versions. > That's "old" keyring (pre-3.5? or 3.4? not sure). The "-eclipse.keyring" is for > the current implementation. OK. But so far I never saw the exception until this week. If there would be a UI, what would it tell me?
I wrote an Eclipse Plugin and have the same problem. I'm working on Windows 10 x86_64. Eclipse 32 bit saves a password in the equinox secure storage (%USERPROFILE%\.eclipse\org.eclipse.equinox.security\secure_storage). The same password (same path and ID) is used in a 64 bit Eclipse. Only one of the two Eclipses can successfully access the password. I tested the following: I wrote the secure storage with the 64 bit Eclipse. The 32 bit Eclipse can't read the password (doesn't find the password provider). I edited the secure storage and removed the 64/64bit suffixed of "windows64"/"windowspasswordprovider64bit". Then, the 32 bit Eclipse can read the password without problems. So it looks like the Windows API returns the same password regardless of the bitness of the used API. This would make the two password providers compatible. My suggestion is to create "proxy" password providers: In Eclipse 32 bit, create a org.eclipse.equinox.security.windowspasswordprovider64bit which redirects all requests to org.eclipse.equinox.security.windowspasswordprovider. In Eclipse 64 bit, create a org.eclipse.equinox.security.windowspasswordprovider which redirects all requests to org.eclipse.equinox.security.windowspasswordprovider64bit.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=527772 seems to have the same problem with Windows 32/64 bit password provider.
There is no longer 32 bit eclipse so probably this one should be closed.
(In reply to Alexander Kurtakov from comment #8) > There is no longer 32 bit eclipse so probably this one should be closed. No interest in this one obviously.
