I guess this (https://sourceforge.net/forum/forum.php?thread_id=3017458&forum_id=880712) forum thread is about the same topic.
Over there is a description of a workaround, which has been tested to work (thanks corvi42 for the test).
Besides that I plan to build a V0.8 beta2 Version within the next few days, where this workaround could be included.
BUT I am not sure what happens to Mac users on older Mac OS X versions...
Cheers,
Roxon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The solution you describe is exactly the same as in the other thread, namely to replace the swt jar with a 64 bit version (though with a newer swt version).
In order to provide mac users of 32bit <b>and</b> 64bit jvms with a version of java passwordsafe, there is still a need for two build targets in our deployment process.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here's what i did to render pws 0.7.105 useable on Leopard 1.5.8 (i'm still
evaluating PasswordSafeSWT !):
The problem: SWT wants to run 32-bit code, Leopard defaults to launching pws
in a 64-bit environment, but the two don't party. Luckily, leopard seems to
have a 32-bit java envionment available but it is not the default.
Fortunately, you can tweak PasswordSafeSWT.app to 'request' a 32-bit java
machine - thereby enabling pws and your Mac to 'get it on'.
What I did: Go to /Applications and find PasswordSafeSWT.app. Right mouse on
it and select 'Show Package Contents'. The .app is really a directory and not
a file, and doing what I just said will enable you to look into the
subdirectories of 'PasswordSafeSWT.app'. Now you need to do a 1 line edit of
Info.plist. Doubleclick on it to edit it (you are about to do the mac
equivalent of editing a .ini file on windows --- remember when!). Expand the
right-pointy arrow next to "Java" at the bottom of the plist. You
will see an attribute called 'JVMVersion' with property set to
"1.5+". Leave this as it is. Now right-mouse on JVMVersion and
select 'Add row' from your pop-up menu, and Add a new attribute called
'JVMArchs'. Set the Value column of your new row to "i386". Hit the
usual red 'Close' button on this mac window - at which point you'll be asked
to save your changes. Save them.
What you have just done is inserted an 'advisory' directive in your startup
file for this application which will attempt to run with a 32-bit java-
virtual-machine instead of the default (incompatible) 64 bit machine.
My observations whilst testing this workaround are below - I cannot tell
whether this workaround has manifested these bugs, or whether these bugs are
just ... bugs in the code, but first impressions are that the sanity of the
underlying password file seems intact when I run against a version-2 data file
(I'd already created the latter by using the macports command-line version,
called 'pwsafe' and was pleasantly surprised that PasswordSafeSWT could work
with this data file ). Anyways, my list of bugs would be:
Preferences: anything to do with re-entering the password to unlock the database, doesn't work. It could just be that the 're-enter database password' dialog box is screwed. The good news is that your master password will still work when you launch the app, so best advice is not to 'enable' any of the Security preferences that will re-lock the database eg after inactivity, minimization etc.
Dont 'omit' to assign a Group to any entry, leastways when using a verision-2 database file format. Nothing bad will happen, but it makes your GUI listing of passwords look cosmetically strange if you dont enter a Group assignation (ie the integrity of the password database is not affected).
So, in summary, I seemed to get an awful lot of program running, just for the
want of adding a single line to a config file ! Happy so far!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got a Mac OS X 10.5.8 (Intel) and tried to upgrade passwordsafe v 6.0 to 7
or the 8 beta. Thanks to exchanging the swt.jar () I managed to finally start
the programm. However, I could not open my existing password file. My correct
password is considered invalid and both new versions cannot import the files I
exported previous to the update (neither text nor xml). Help would be much
appreciated.
PasswordSafe no longer launches after the recent Mac java update.
Hi all,
I guess this (https://sourceforge.net/forum/forum.php?thread_id=3017458&forum_id=880712) forum thread is about the same topic.
Over there is a description of a workaround, which has been tested to work (thanks corvi42 for the test).
Besides that I plan to build a V0.8 beta2 Version within the next few days, where this workaround could be included.
BUT I am not sure what happens to Mac users on older Mac OS X versions...
Cheers,
Roxon
That solution is absolute bunk. You do not need to switch the JVM (though you could). Here's my solution
http://compileyouidontevenknowyou.blogspot.com/2009/08/passwordsafe-on-osx.html
The solution you describe is exactly the same as in the other thread, namely to replace the swt jar with a 64 bit version (though with a newer swt version).
In order to provide mac users of 32bit <b>and</b> 64bit jvms with a version of java passwordsafe, there is still a need for two build targets in our deployment process.
Okay, my bad. I thought he/she proposed using a different JVM. Thanks!
I have encountered the same problem, and can no longer use PasswordSafe. Is there any workaround available? Is there a plan to resolve this? Thanks!
yea! I was the original poster and I'd been using password gorilla to get at my password file for a few days. glad to have passwordsafe back!
Here's what i did to render pws 0.7.105 useable on Leopard 1.5.8 (i'm still
evaluating PasswordSafeSWT !):
The problem: SWT wants to run 32-bit code, Leopard defaults to launching pws
in a 64-bit environment, but the two don't party. Luckily, leopard seems to
have a 32-bit java envionment available but it is not the default.
Fortunately, you can tweak PasswordSafeSWT.app to 'request' a 32-bit java
machine - thereby enabling pws and your Mac to 'get it on'.
What I did: Go to /Applications and find PasswordSafeSWT.app. Right mouse on
it and select 'Show Package Contents'. The .app is really a directory and not
a file, and doing what I just said will enable you to look into the
subdirectories of 'PasswordSafeSWT.app'. Now you need to do a 1 line edit of
Info.plist. Doubleclick on it to edit it (you are about to do the mac
equivalent of editing a .ini file on windows --- remember when!). Expand the
right-pointy arrow next to "Java" at the bottom of the plist. You
will see an attribute called 'JVMVersion' with property set to
"1.5+". Leave this as it is. Now right-mouse on JVMVersion and
select 'Add row' from your pop-up menu, and Add a new attribute called
'JVMArchs'. Set the Value column of your new row to "i386". Hit the
usual red 'Close' button on this mac window - at which point you'll be asked
to save your changes. Save them.
What you have just done is inserted an 'advisory' directive in your startup
file for this application which will attempt to run with a 32-bit java-
virtual-machine instead of the default (incompatible) 64 bit machine.
My observations whilst testing this workaround are below - I cannot tell
whether this workaround has manifested these bugs, or whether these bugs are
just ... bugs in the code, but first impressions are that the sanity of the
underlying password file seems intact when I run against a version-2 data file
(I'd already created the latter by using the macports command-line version,
called 'pwsafe' and was pleasantly surprised that PasswordSafeSWT could work
with this data file ). Anyways, my list of bugs would be:
So, in summary, I seemed to get an awful lot of program running, just for the
want of adding a single line to a config file ! Happy so far!
Hi nobody,
thanks for your detailed description, I included this key in the new 0.8 beta
2 release fro macs.
I am bit suprised about the effects with passphrase entry you describe while
testing, they might be due to using a v2 database.
Can you reproduce them with a new passwordsafe created with PasswordSafe SWT
(defaults to v3 database)?
I believe v2 does not support group entries, but that behaviour is still
wrong. Could you file this as a bug, please?
I got a Mac OS X 10.5.8 (Intel) and tried to upgrade passwordsafe v 6.0 to 7
or the 8 beta. Thanks to exchanging the swt.jar () I managed to finally start
the programm. However, I could not open my existing password file. My correct
password is considered invalid and both new versions cannot import the files I
exported previous to the update (neither text nor xml). Help would be much
appreciated.
Stephan
: http://sourceforge.net/projects/jpwsafe/forums/forum/880712/topic/3378720
Actually, it crashes completely. Even if I want to create a new password file.
Stephan
Stephan, exchanging the swt.jar shouldn't be necessary anymore with
PasswordSafeSWT-0.8-beta2a.dmg download.
Can you confirm this?
On Snow Leopard 10.6.2 with latest JVM (1.6.0_17), which has a 64-bit hotspot
JVM.
Just tried
PasswordSafeSWT-0.8-beta3-x86_64.dmg
error message is
java.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM
Then I tried
PasswordSafeSWT-0.8-beta3-carbon.dmg
and the DMG is not mountable.
.7, just like .8, does not work correctly if you sub in the 32-bit SWT. This
is the error
org.eclipse.swt.SWTException: Failed to execute runnable
(java.lang.NullPointerException)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Unknown Source)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at
org.pwsafe.passwordsafeswt.PasswordSafeJFace.main(PasswordSafeJFace.java:486)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at apple.launcher.LaunchRunner.run(LaunchRunner.java:115)
at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50)
at
apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)
Caused by: java.lang.NullPointerException
at org.eclipse.swt.widgets.Shell.sendToolTipEvent(Unknown Source)
at org.eclipse.swt.widgets.Shell.windowSendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.windowDelegateProc(Unknown Source)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Display.applicationSendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.applicationProc(Unknown Source)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at org.pwsafe.passwordsafeswt.dialog.StartupDialog.open(Unknown Source)
at org.pwsafe.passwordsafeswt.PasswordSafeJFace.displayOpeningDialog(PasswordS
afeJFace.java:206)
at org.pwsafe.passwordsafeswt.PasswordSafeJFace.access$0(PasswordSafeJFace.jav
a:199)
at
org.pwsafe.passwordsafeswt.PasswordSafeJFace$1.run(PasswordSafeJFace.java:238)
at org.eclipse.swt.widgets.RunnableLock.run(Unknown Source)
... 13 more
Please help as if I didn't have my Sourceforge password in Firefox, I would've
had to post as anonymous :)
THANKS!
Try to download again PasswordSafeSWT-0.8-beta3-carbon.dmg.
On my side it is mountable and that's the version I installed. It works with
10.6.2 1.6.0_17
@nobody, thanks! Indeed
PasswordSafeSWT-0.8-beta3-carbon.dmg
works perfectly now. Great news! Long live Password Safe!