'Multiple copies installed' update dialogue

sjn

This is just an annoyance, not a problem, but .... recently, I've been getting the 'update failed - multiple copies installed' dialogue (maybe since updating to v6?) As described elsewhere, 1P is finding copies on mounted backup drives, and sees them as conflicting.

Dismounting backup drives before updating prevents it, of course. And I can also hit 'update anyway' in the dialogue - thank you for providing that sensible option : -)

But wouldn't it make more sense for 1P to only try to update the currently launched version?

---

1Password Version: 6.0.1
Extension Version: 4.5.2.90 (Chrome)
OS Version: 10.8.5
Sync Type: Dropbox
Referrer: kb-search:multiple copies, kb:remove-multiple-apps

Stephen_C

@sjn please see this AgileBits' recent post which explains clearly the source of this annoyance.

This knowledge base article covers the situation:

How to remove multiple, conflicting copies of 1Password from your system

Note the last section about backup drives. The solution (if you wish to have the backup drive permanently connected) is to:

• delete any copy of the 1Password app file (only) from the backup drive; and
• exclude the 1Password app file from any further backups (because, of course, you can always re-download it if you need to).

Provided you don't use any app cleaner tool when deleting the app file none of this will interfere with your 1Password data.

Stephen

AGAlumB

@sjn: It is 'safe' to ignore this message if you're comfortable with this setup. But as a precaution we want to warn people about this since OS X may launch the wrong copy and cause some headaches by interrupting 1Password's normal functioning. Be sure to let me know if you have any questions! :)

sjn

@Stephen_C: Thanks for the link to the previous thread - interesting to get more 'under the hood' info. I had read that KB article already, but would prefer not to have to massage all my backup routines as a workaround.

@brenty: Thanks for for reassurance. So far, I've never had any 'mis-launches' (and I am careful to have only one copy on my startup drive) - but I'll be extra vigilant about it now.

Jacob

@sjn On behalf of Stephen and brenty, you're welcome. If you ever need anything else, feel free to let us know.

wpl38

The new update dialogue has been an annoyance to me as well. In the interest of caution, I've so far been dismounting my backup drive every time, which is a pain. The suggestion that we delete the 1Password copy on the backup drive is not very helpful, since that means we have to do that every time the drive auto-clones—in my case only weekly, but for some people this would be daily.
My immediate question is this. I never ever had a problem before with 1Password updating the wrong copy (i.e., the copy on my backup drive). Has anything changed in the way the update works that might make updating the backup copy a greater probability now? If not, I will happily click the "Update anyway" button.
But there has to be a better way. Why not assume by default that all copies on external drives are not active and make sure the updater ignores them by default? Then a message is only needed if the updater finds multiple copies on the main/internal drive, OR if the only copy found is on an external drive (in which case the message would simply need to confirm that that's the copy in need of updating, so the updater will not ignore it). Throwing up a disturbing error message for everyone who has a backup copy attached is poor interface design.

danco

I'm not sure, but I believe the issue is not that the updater might update the wrong copy, but that if you have more than one copy then running 1PW may run into difficulties (due to an Apple bug with launchd). So AgileBits decided to flag the issue at the time of update.

Almost any way of creating a backup drive allows for excluding individual files (such as the 1PW app) from the backup.

You could also try (which is worth doing anyway) excluding the backup drive from Spotlight; this seems to work for many of us.

rickfillion

Hi @wpl38,

As @danco notes, the issue isn't that we might accidentally update the wrong app. That's not going to happen, we're going to update the one that's running and leave the others alone. The problem is that upon relaunching the app we're not guaranteed to be able to communicate with the right 1Password mini if you've got multiple on your Mac (even if only on a backup drive). The mechanism we use simply lacks the ability for us to specify exactly WHICH mini we want to communicate with, and the system has to make an educated guess. That guess can be wrong (it happens more often than you'd think). If it picks the wrong one... it currently hangs the 1Password app.

We will be doing improvements in a future version of 1Password that will help with some of this, but only to a certain degree. We're still at the mercy of launchd, and it may still launch the wrong one.

Multiple instances of 1Password on peoples' disks and launchd choosing the wrong one is our number one source of problems. We've decided that it's time to actively ask users to help us with it.

I hope that helps explain things.

Rick

wpl38

Thanks to Danco for clarifying what Stephen_C's 2nd suggestion meant. I guess I knew it was possible to exclude individual items in SuperDuper, but had never done so, so it didn't click.

And thanks to rickfillion for explaining more clearly what the problem is. I gather that even though the problem is with launching the right 1Password Mini, it's just the extra 1Password.app(s) that I need to remove rather than any other support file(s)?

Vee_AG

I gather that even though the problem is with launching the right 1Password Mini, it's just the extra 1Password.app(s) that I need to remove rather than any other support file(s)?

Yes, @wpl38! That's exactly right. :+1: