Deleting logins from app does not persist to 1Password.agilekeychain sometimes

ZildjianKX

Sometimes when I delete a login, the 1Password.agilekeychain does not get updated with the change. If I open the HTML file in the package, it doesn't reflect the deletion, and dropbox never syncs anything, so the change doesn't show up on my other systems. Any suggestions on how to resolve this?



Edit - I've tried killing the 1Password Helper, deleting the containers for both 1Password and 1Password Helper and restarting/reinstalling, and still the problem persists.



Edit - So it appears anything I do in 1Password is not getting persisted to the keychain, but it still appears in the app UI, even after a restart... so confused.



Edit - So ~/Library/Containers/com.agilebits.onepassword-osx-helper/Data/Documents/1Password.agilekeychain properly gets updated, which I guess is what the app relies on, but the path I chose for dropbox, ~/Dropbox/1Password.agilekeychain, isn't.

ZildjianKX

Can anyone form agilebits comment about when the agilekeychain in the container is supposed to sync to the agilekeychain in the user's dropbox that they chose? Is this a sandboxing issue? Should I just delete the agilekeychain in my drop and symbolic link to the one in the container?

ZildjianKX

So I've looked into this a bit more, and the issue seems to arise from me doing the following:



1) Quit the helper

2) Delete all the containers for 1Password in application support

3) Starting 1Password and choosing existing user, and pointing to the keychain in my dropbox

4) From this point forward, the keychain does not properly update



If I choose new user, it somehow still found my old entries in the previous keychain, renamed the previous keychain, and now everything syncs fine. I think there is a serious bug with choosing existing user and getting the keychain file to update in the dropbox folder. Can someone from Agilebits please comment?

khad

Sorry for the delayed reply, ZildjianKX. The browser extensions are sandboxed for security and sync back to the main application via an encrypted [url="http://en.wikipedia.org/wiki/WebSocket"]WebSockets[/url] channel. What can happen in some cases is that the data still present in the extension database(s) can get synced back to the main application even after you create a new data file.



If your goal is to truly start over, you will need to remove the browser extensions before creating a new data file at this time. This should be fixed in the next update.



I hope that helps. Please let me know.

ZildjianKX

The main issue I'm having is selecting the "I have already used 1Password" option on first launch and choosing an existing keychain in my ~/Dropbox folder is severely broken. It reads in the keychain, but it doesn't update the keychain bundle at ~/Dropbox after any updates have been made to "Logins" in the 1Password.app. Only:



[quote]~/Library/Containers/com.agilebits.onepassword-osx-helper/Data/Documents/1Password.agilekeychain[/quote]



is getting updated.



[quote]~/Dropbox/1Password.agilekeychain[/quote]



never gets updated.



If I choose "I am a new user" at first launch, it reads in my old keychain (I guess as you described above) and the agilekeychain file updates fine in ~/Dropbox. I think there is a severe bug with the "I have already used 1Password" option. Can someone from QA please try to repo the problem? I hit it 100% of the time on all 3 of my Macs and it's driving me crazy.

khad

We have updated the code for the next update to handle these sorts of situations better, but those two data files are completely different and not linked in any way. There should only be one data file located [i]either[/i] at ~/Library/Containers/com.agilebits.onepassword-osx-helper/Data/Documents/1Password.agilekeychain [i]or[/i] ~/Dropbox/1Password.agilekeychain. There is no reason for a data file to exist in both locations. Verify which one is being used by 1Password and then try moving the other to your Desktop to get it "out of the way". 1Password 3.9 has an order in which it looks for your data if you tell it that you are an existing user. In 1Password 3.9, if you have data in both locations, the one in the container will be detected first and used. My understanding is that we are going to handle this by looking at the last modified date going forward, but I cannot be certain of the specifics of it.

ZildjianKX

Yeah, it was definitely using the one in the container. If I moved or deleted that one, it wouldn't find the one in my dropbox and would just prompt me if I'm a new user or not. I pretty much have to tell it I'm a new user, have it setup a new keychain in my dropbox, then I copy over it. It makes it really hard to sync multiple machines with the same keychain.

khad

If you already have a data file in Dropbox when you install 1Password it won't create one in the container, so if you install Dropbox on another machine first, wait for it to finish syncing, and then install 1Password it should detect everything properly.



If you create a new data file first, though, it will be in the container. Installing Dropbox afterwards creates another data file which will be ignored since you already created and are using a separate data file.



We're adding a merge function in case you accidentally create a new local file and populate it with data before setting up Dropbox sync with another machine.



If there is only one data file in Dropbox — only one is supported — each machine will sync properly with it. It is when you also have a data file in the container that trouble arises. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_worried.png' class='bbc_emoticon' alt=':S' />



We will be handling this better in the next update.

ZildjianKX

Thanks for the reply. What you said makes sense, but I think there is still a bug with the current behavior.



1. Disable the helper from 1Passwor's preferences

2. Quit 1Password

3. Delete the containers from ~/Library/Containers

4. Launch 1Password, select existing user, browse to the keychain file in ~/Dropbox

5. Observe the results



- Actual -

A keychain is generated in:

~/Library/Containers/com.agilebits.onepassword-osx-helper/Data/Documents/1Password.agilekeychain

which appears to be a copy of the keychain in ~/Dropbox. The ~/Dropbox keychain is ignored for all future updates



- Expected -

A keychain is not generated in:

~/Library/Containers/com.agilebits.onepassword-osx-helper/Data/Documents/1Password.agilekeychain



Only the keychain in ~/Dropbox is used.



- Note - Dropbox is fully synced in the above scenario.

khad

[quote]I think there is still a bug with the current behavior.[/quote]

Yep. I agree. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' /> That's why I said we will be handling this better in the next update.



And, that "next update" is just around the corner, now! We've submitted 3.9.1 to the Mac App Store and are just waiting for Apple to approve it now. Please let me know if you are still having trouble with 3.9.1 once you are able to install it.