Updates are a pain on desktop Mac

raja99

Backup drives

If you use a backup program such as Time Machine, SuperDuper! or Carbon Copy Cloner, backed-up copies of the 1Password app may be conflicting with the main app installed on your Mac.

To avoid this problem, make sure that your backup drive is disconnected when you launch 1Password.

I'll be surprised if I'm the first person to bring this up, but: Our iMac has nightly scheduled SuperDuper! backups, plus occasional backups to another partition if I want to make a snapshot before a major upgrade. Therefore if 1Password says there's an update, the simplest way for me to install it is to

1. Launch Disk Utility
2. Locate and eject the two backup partitions
3. Quit 1Password
4. Reopen 1Password and tell it to update
5. Go back to Disk Utility and locate and remount the two partitions

which is a pain and means that if an update request happens when someone else is using the computer they basically have to grab me and get me to do it.

Might you consider adding a setting to tell 1Password to only update the file in the path it launched from, or a user-specified path in the preferences (default: /Volumes/Macintosh\ HD/Applications/ ) ?

Thanks.

---

1Password Version: 6.2.1
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: kb:remove-multiple-apps

danco

Actually the problem is not with the update ("Update anyway" should work fine) but with the fact that multiple copies of 1PW can cause problems later on. And this is a bug with Apple's launchd process. I'm not sure if AgileBits could or should try to work round this.

The passage you quote really needs changing to reflect the situation more accurately.

First, for SuperDuper or CCC backups, you could just keep the drive unmounted, as the programs will mount them for scheduled backups.

Second, it is easy to exclude 1PW from a backup. The data will get backed up anyway, and the program could be redownloaded if needed.

Third (not so reliable, but maybe simplest) you could try excluding the backup drives from Spotlight.

raja99

Thanks for your comments.

"Update anyway" sometimes works, sometimes it doesn't. Which is to say, I used to do it all the time, until once it insisted on updating the copy on my nightly backup instead of on Macintosh HD, and from then on it only seemed to update that copy. This is not useful.

Good to know that SuperDuper! will automatically mount the backup partition for a scheduled backup.

Why on earth would I want to exclude 1Password from my backups? The point of having a complete, bootable backup is to have a fully-functional system (albeit a little slow) if the internal drive dies. Similarly, why would I want to exclude backup drives from Spotlight? Are you saying that when 1Password runs an update, it uses Spotlight to find the location of its own application files? That seems ... odd.

I'm sorry but it sounds like you're suggesting I make several changes to the way I use my Macintosh to avoid having 1Password store its own path. If there is a good technical reason it can't be done, that's one thing. (It's a very odd thing, but I could at least understand it.) Is there a reason why this couldn't be done?

littlebobbytables

Hi @raja99,

Inside the 1Password application bundle is a helper process titled 1Password mini. The way we have to register 1Password mini with OS X is by specifying an ID but this ID is the same in every copy of 1Password, it can't change. This ID is all we're allowed to specify when registering 1Password mini with launchd and the issue we face is when we ask OS X to launch 1Password mini we can't say where it lives. launchd uses the Spotlight database and it simply returns the first instance it finds and while it might that it found one in your /Applications/ folder for days, weeks or even months one day it might say it found one on your backup drive and start using that. This is sadly out of our control for as long as we use a helper process and moving away from using this is not a small venture, it will be a massive upheaval as we're basically talking about rewriting massive chunks of how 1Password works. Do we still believe it needs to happen, yes, it's just it won't be a quick fix.

As it is out of our control and as having OS X launch a wrong copy causes all sorts of grief that you really want to avoid the only options we can think of for right now are to ensure multiple copies are not accessible.

You're correct that excluding the 1Password application bundle from your backup will mean it isn't a perfect clone and in the event that you need to use the clone drive you would need to download a fresh copy of the application. At this point though it would pick up from where it left off as you're still backing up the entire support folder which contains preferences, backups and most importantly your vaults. Do we like suggesting you exclude the application bundle from your backup? not in the slightest, it's just the only real option we've come up with so far that definitely works.

raja99

Thanks for giving more of an explanation of the situation. I can definitely sympathize with "Do we still believe it needs to happen, yes, it's just it won't be a quick fix." I have situations like that at work. I inherited a large codebase (in a programming language I don't know and that was never mentioned in the interview!). The inherited stuff mostly works without problems, except when the web server team periodically decides to upgrade the runtime it uses :-/ .

Your username and avatar gave me a chuckle; I will keep you away from my work website.

Thanks again.

AGAlumB

Indeed, while it's still a lot of work, it's nice when you at least have access to the codebase. That's not a luxury we have with launchd. :lol: