SD no longer honouring backup-on-mounting-drive
 

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.

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.

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?

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.

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.

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'.

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.

Which was, effectively, a different location.

Since none of the above worked: Brute Force approach
 

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.

Problem re-occurred: Deleting backupponmount plists solved it
 

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.

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

What do you mean with 'turning off the backups'? Unchecking both checkboxes in the dialogue box showing up when clicking Edit in the 'Scheduled Copies' window?

And it now does so, ie, deleting the scheduled copies removes those two plist files. I only had discovered these two files relatively late in my debugging process (I was first only looking out for files with 'superduper' in their name). It is thus possible that I had set up a new scheduled copy (which didn't work), then deleted all files with 'superduper' in their name without first deleting the scheduled copies from within SuperDuper with therefore these two files remaining.

In short, I cannot say for sure that deleting the scheduled copies from within SD did not delete these two plist files. I only know that a new 'installation' of SD, encountering these two files failed to start upon mounting a destination volume (of a newly scheduled copy). And I know that only deleting the scheduled copies from within SD followed by deleting their folder in Application Support did not solve the problem.

But the next time this occurs, I will first check whether deleting the scheduled copies from within SD actually removes those two files or if them getting stuck might have caused that problem. (I might even be able to test this by booting of a clone from a few days ago.)

I mean deleting the scheduled copies, or unchecking the checkboxes, will delete those files. Since I originally told you to delete them, they were removed already, and are only back because you recreated the schedules. Why deleting them manually worked I don't know, since - again - they had already been removed.

Exactly same issue here.
Could someone help us, please ?

Thanks in advance.

See my replies to Manu - that will fix it.

I had not seen it.
I am reading it.
Thanks for quick and efficient support.

Solved ! :D

Great! Glad you're fixed.

Problem re-occured - nailed down part of the problem
 

The problem re-occurred (already some time ago but I just now came around to fix it).
In the end, it only started working again after I downloaded a fresh copy of SD and replaced the one in my /Applications folder with it. Before that I went through seven debugging rounds, always repeating all previous measures and adding one or two additional things. I cannot say that replacing SD in Applications was sufficient it but it was a necessary ingredient.

1) Deleted schedules, deleted 'Scheduled Copies' (in ~/Library/Application Support/SuperDuper!, restart computer, re-create schedule, saved SD settings, quit SD, ejected disk, re-connected disk --> nothing happened

2) Deleted schedules, deleted 'SuperDuper!' (in ~/Library/Application Support), restart computer, re-create schedule, saved SD settings, quit SD, ejected disk, re-connected disk --> nothing happened

3) Deleted schedules, deleted
- 'SuperDuper!' (in ~/Library/Application Support) and
- both 'com.shirtpocket.backuponmount' plist files (in ~/Library/LaunchAgents),
restart computer, re-create schedule, saved SD settings, quit SD, ejected disk, re-connected disk --> nothing happened

4) Deleted schedules, deleted
- 'SuperDuper!' (in ~/Library/Application Support) and
- both 'com.shirtpocket.backuponmount' plist files (in ~/Library/LaunchAgents),
- 'blacey.SuperDuper!.savedState' (in ~/Library/ Saved Application State)
- 'SuperDuper!_xxx.plist' (in ~/Library/Application Support/CrashReporter)
restart computer, re-create schedule, saved SD settings, quit SD, ejected disk, re-connected disk --> nothing happened

5) Deleted schedules, deleted
- 'SuperDuper!' (in ~/Library/Application Support) and
- both 'com.shirtpocket.backuponmount' plist files (in ~/Library/LaunchAgents),
- 'blacey.SuperDuper!.savedState' (in ~/Library/ Saved Application State)
(- 'SuperDuper!_xxx.plist' (in ~/Library/Application Support/CrashReporter))
- 'com.blacy.SuperDuper!' (in ~/Library/Caches)
restart computer, re-create schedule, saved SD settings, quit SD, ejected disk, re-connected disk --> nothing happened

6) Deleted schedules, deleted
- 'SuperDuper!' (in ~/Library/Application Support) and
- both 'com.shirtpocket.backuponmount' plist files (in ~/Library/LaunchAgents),
- 'blacey.SuperDuper!.savedState' (in ~/Library/ Saved Application State)
(- 'SuperDuper!_xxx.plist' (in ~/Library/Application Support/CrashReporter))
- 'com.blacey.SuperDuper!' (in ~/Library/Caches)
- 'com.blacey.SuperDuper.xxx.plist' (in ~/Library/Preferences)
- app.com.blacey.Superduper!.playlist (in ~/private/var/db/BootCaches/xxx)
restart computer, re-create schedule, saved SD settings, quit SD, ejected disk, re-connected disk --> nothing happened

7) Deleted schedules, deleted
- 'SuperDuper!' (in ~/Library/Application Support) and
- both 'com.shirtpocket.backuponmount' plist files (in ~/Library/LaunchAgents),
- 'blacey.SuperDuper!.savedState' (in ~/Library/ Saved Application State)
(- 'SuperDuper!_xxx.plist' (in ~/Library/Application Support/CrashReporter))
- 'com.blacey.SuperDuper!' (in ~/Library/Caches)
- 'com.blacey.SuperDuper.xxx.plist' (in ~/Library/Preferences)
- app.com.blacey.Superduper!.playlist (in ~/private/var/db/BootCaches/xxx)
- Replaced SuperDuper!.app in Applications with a newly downloaded copy
restart computer, re-create schedule, saved SD settings, quit SD, ejected disk, re-connected disk --> nothing happened

After step 6) I had to 'unlock' something (probably because I had deleted stuff in /private/var). And when it worked after step 7) I had to authorise a new application inside the SuperDuper! bundle to be run for the first time (because it was downloaded from the internet.

Next time the problem re-occurs, I'll start debugging from the other end (ie, start with replacing SuperDuper!.app and then add the boot caches and so on). If you are interested in the SuperDuper!.app bundled that needed replacing, I can retrieve it from a backup and send it to you.

Sounds more like something had happened to launch services and/or your script dictionary...

And running a new copy of SD for the first time resets something in launch services?

Yes, deleting your existing copy, then reinstalling is going to clear out Apple's cached information about the app.

Should the function 'Rebuild Launch Services Database' in Cocktail (under System -> Databases) do this as well or would it be the 'Clear Caches', System and/or User (under Files -> Caches)?

It should, although it may not re-fetched a cached script dictionary.