SD no longer honouring backup-on-mounting-drive

[Manu Chao]

For the last two weeks or so, SD no longer starts a backup when connecting an external drive. I have tried to set it again but it does not start.

Starting the backup manually works fine.

[dnanian]

Nothing happened about two weeks ago that preceded these failures?

[Manu Chao]

Originally Posted by dnanian

Nothing happened about two weeks ago that preceded these failures?

Apart from the year changing from 2012 to 2013, no. Maybe there was an OS crash (requiring a forced shutdown) in between, I had one recently (in the last couple of weeks) but I cannot remember exactly when that was.

So, if this is not a problem frequent enough that some possible causes are known that could suggest a course of action, I will try the usual: re-install the SuperDuper and try a new OS user account.

[dnanian]

I'd actually:

• Delete all existing schedules
• Remove the "Scheduled Copies" folder in ~/Library/Application Support/SuperDuper!
• Restart your Mac
• Recreate the schedule

[Manu Chao]

Originally Posted by dnanian

I'd actually:

• Delete all existing schedules
• Remove the "Scheduled Copies" folder in ~/Library/Application Support/SuperDuper!
• Restart your Mac
• Recreate the schedule

I've tried it in a new user account which by default starts without a folder 'Scheduled Copies' and no existing schedules and required me to re-create the schedule. I also had just restarted my Mac just two days ago, ie, well after the problem occurred. I also installed a new copy of SD into the new users's Application folder.

At first, it did not work in the new user account either but then I tried two things: (1) logged out and back into the new user account and (2) connected the external drive directly (it was the third device in FW chain before). After that (I cannot say which of the two steps did the trick), it worked, even after putting the device back again in its normal position in the FW chain.

Unfortunately, when I tried it again in my regular user account, it did not work (after following your steps). I can try to delete all SuperDuper content from ~/Library but maybe something else (non shirt-pocket stuff) is wrong with my main user account. Is SD relying on other things (eg, folder actions on /Volumes) to do the start upon connecting feature?

[dnanian]

We've simply got a LaunchAgent that is run when volumes are mounted, and then we look for the volume you scheduled with. If you've done everything I've suggested, perhaps something is preventing the launch. But that would be weird.

[Manu Chao]

Originally Posted by dnanian

We've simply got a LaunchAgent that is run when volumes are mounted, and then we look for the volume you scheduled with. If you've done everything I've suggested, perhaps something is preventing the launch. But that would be weird.

Can you give me the name of that launchagent (so, I can filter for it in Activity Monitor and see if it shows up when I connect my drive)?

I just tried something else that worked: I put a (newly downloaded) copy of SD into main user account's Applications folder. Launched, set the schedule there and it worked (I also hit a cmd-S on the main SD window which prompted me to save an Untitled settings file. Am I supposed to do this after every schedule change? And it also asked me to unlock SD but that was probably because I had launched this copy of SD for the first time).

Then I launched my main SD (in /Applications), tried the cmd-S thing there as well (it asked whether I wanted to overwrite older settings, I said yes). But after than, things did not work again. So, I deleted again all scheduling stuff (inside SD and the folder in the ~/Library) and all stuff in ~/Library/.../Saved Settings) and setup the schedule again from the copy of SD in my user folder and it worked again.

[dnanian]

Why do you have it in a user's Application folder rather than in /Applications?

It sounds like you have a bunch of copies of SD! installed that you shouldn't.

The launch agent's identifier is com.shirtpocket.backuponmount (and there's a com.shirtpocket.backuponmount-login as well). But that won't be visible in activity monitor.

[Manu Chao]

Originally Posted by dnanian

Why do you have it in a user's Application folder rather than in /Applications?

It sounds like you have a bunch of copies of SD! installed that you shouldn't.

I probably wasn't clear enough. Until a few hours ago there was only one copy of SD installed, and it resided in /Applications, ie, the original problem occurred and persisted with only one copy of SD installed.

Then, to start with a slate as clean as possible, I created a new user account, installed a fresh copy of SD in that new user account to get a new install without changing anything in my existing system. Things did not work initially but after a re-login, they worked.

Back in my main account, things still did not work (even after carrying out your four steps twice). So, I thought, maybe I do need a fresh install of SD. And to again keep the existing system as it was, I installed the new copy in my user's Application folder. And thankfully that worked, so either placing SD in my user folder or the action of 're-installing' SD solved it.

Just for verification I again deleted all schedules (incl. folder in ~/Library/...) and running the copy of SD in /Applications. That was not successful and it also broke the 'work-around' (SD in ~/Applications). But I was able to re-activate my work-around (presumably by deleting the content of the Saved Settings folder and/or by recreating the schedule from the copy of SD in ~/Applications).

My next step is to delete everything related to SD in my user Library and try again. Then also replace SD in /Applications and try again. But that will happen tomorrow because my backup disk is now in its usual off-site location.

So, in short, whenever I set the schedule from a copy of SD inside a user folder things worked. This might be because of the location or because that was associated with a 're-install'.

[dnanian]

When you move the location of the app, it may force itself to reconnect its internal links to files in its bundle. My steps will do that too.

[Manu Chao]

Originally Posted by dnanian

When you move the location of the app, it may force itself to reconnect its internal links to files in its bundle. My steps will do that too.

I didn't move the location of the app, I downloaded a new copy from your website, placed it into ~/Applications and launched that copy from there by double-clicking it.

[dnanian]

Which was, effectively, a different location.

[Manu Chao]

Deleted everything with 'superduper' in its name (found by Find Any File). Copied SuperDuper from its disk image into /Applications, set-up a new copy script, logged out of my account, logged back in and then it worked.

[Manu Chao]

Even deleting all files with the word Superduper in their name (incl. the application) did not fix the problem (ok, I kept the files in /private/var/root and /private/var/log).

Deleting the two files:
~/Library/LaunchAgents/com.shirtpocket.backuponmount.plist and
~/Library/LaunchAgents/com.shirtpocket.backuponmount-login.plist

however, fixed it. Which is probably not completely surprising. And since the problem re-occurred within about three months (it re-occurred two months ago, I only now got around to fix it) maybe there is a pattern as to what triggers the failure.

[dnanian]

What's weird is that simply turning off the backups (or removing them), and quitting SD, will remove those agents...