Bugzilla – Full Text Bug Listing
| Summary: | Mylyn doesn't remember credentials for Bugzilla (AuthorizationDatabase.save fails on Windows PC) | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Tobias Oberlies <t-oberlies> |
| Component: | Mylyn | Assignee: | Mylyn Inbox <mylyn-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | Jesse.Weinstein, lmcbout, mark, matthias.schmalz, sascha.scholz |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Tobias Oberlies
Forgot to mention: I tried both an Oracle jdk1.6.0_30 VM and an Oracle jdk1.7.0_05 VM, and the symptoms are the same. What version of Eclipse is this? Bug says 4.2 but AuthorizationDatabase no longer exists in Eclipse 4.2. This is not Equinox secure storage but rather than Eclipse 1.0 keyring mechanism that was deprecated long ago. I have installed the Eclipse SDK (org.eclipse.sdk.ide) in version 4.2.0.I20120608-1400. Maybe the deprecated mechanism is pulled in by a different feature, possibly the Mylyn Bugzilla Connector (org.eclipse.mylyn.bugzilla_feature.feature.group/3.8.0.v20120612-0600). Mylyn was a good guess: org.eclipse.mylyn.tasks.core/3.8.0.v20120612-0600 has a Require-Bundle: org.eclipse.core.runtime.compatibility.auth;resolution:=optional;x-installation:=greedy This also matches the observation that the error happens when configuring a Bugzilla task repository. Should this bug be moved over to Mylyn with the request to remove the dependency on the broken&deprecated implementation? (In reply to comment #4) > This also matches the observation that the error happens when configuring a > Bugzilla task repository. Should this bug be moved over to Mylyn with the > request to remove the dependency on the broken&deprecated implementation? Yes. Here is the related Juno migration guide entry: http://help.eclipse.org/juno/topic/org.eclipse.platform.doc.isv/porting/4.2/incompatibilities.html?cp=2_3_0_2#runtime-auth Tobias, is C:\Env\Eclipse\Installation\juno\configuration\org.eclipse.core.runtime\.keyring writeable to the user that is running Eclipse? I have seen the issue on two PCs now, with and without SSD. It has always been a general Mylyn issue for me, not related to one task repository. I remember vaguely, that it was gone when I switched back from a 64bit to a 32bit JVM. But I'll have to verify this. (In reply to comment #6) > Tobias, is > C:\Env\Eclipse\Installation\juno\configuration\org.eclipse.core.runtime\.keyring > writeable to the user that is running Eclipse? Yes, it is. I checked the permissions, and they look normal. eclipse.exe is running as my user, and that user has full control in the file system. I see this bug with eclipse.buildId=M20120208-0800 java.version=1.7.0_07 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Framework arguments: -product org.eclipse.epp.package.cpp.product Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.cpp.product It happens with two versions of Mylyn: 3.8.1.v20120725-0100 and 3.6.5.v20120215-0100 . Assuming it's related to org.eclipse.core.runtime.compatibility.auth (3.2.200.v20110110) "Authorization Compatibility Plug-in" [Active] that's its version. *** Bug 390123 has been marked as a duplicate of this bug. *** Darn, my Eclipse password expired, and now I'm getting hit by this again. To make sure I don't forget this myself, I am posting here how to work around this: * Start the main workspace in debug mode: eclipse -vmargs -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 * Start a second workspace * Import org.eclipse.core.runtime.compatibility.auth in that workspace and place a method breakpoint at the entry of AuthorizationDatabase.save * Launch a "Remote Java Application" debugging session * In the main workspace, update the credentials of the Eclipse Bugzilla task repository * In the debug workspace, step through the save method, resume on the last line of the method (four times) Done! I see the error with: eclipse.buildId=4.3.0.I20130314-1330 java.version=1.6.0_23 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86_64 Mylyn Tasks 3.9.0.I20130319-0842 org.eclipse.core.runtime.CoreException: Unable to write to authorization database: C:\Users\mdvanals\Documents\eclipse-SDK-4.3M6-win32-x86_64\eclipse\configuration\org.eclipse.core.runtime\.keyring. at org.eclipse.core.internal.runtime.auth.AuthorizationDatabase.save(AuthorizationDatabase.java:331) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) Caused by: java.io.IOException: Access is denied at java.io.WinNTFileSystem.createFileExclusively(Native Method) at java.io.File.createNewFile(Unknown Source) at org.eclipse.core.internal.runtime.auth.AuthorizationDatabase.save(AuthorizationDatabase.java:323) Updated title so that I find the bug faster next time I run into this problem again. Today, it took me a while to find it. Mylyn 3.11 has been updated to use the Equinox secure storage. The Eclipse keyring is no longer supported in Mylyn, so this specific issue won't be fixed. (In reply to comment #14) > Mylyn 3.11 has been updated to use the Equinox secure storage. As of comment #5, this is exactly what was needed to fix this issue. So IMHO this bug should be marked as FIXED. *** This bug has been marked as a duplicate of bug 393722 *** |