PDA

View Full Version : Dead <Copy now> on scheduled-backup list


Irl
10-26-2010, 09:48 AM
I have several backups on the "Scheduled backups" list. Usually, if I select one and click "copy now", it runs. I had some system issues (somehow the finder's plist permissions got reset to "nobody can use this"). While fixing those I killed off all my startup items to try to figure out why the Finder wouldn't start; I don't know whether it's related to the problem: now the SD "copy now" button on the "Scheduled Backups" panel does nothing. I can still go to the main panel, select source and destination volumes, and use the script the schedule is supposedly using ('backup -- all files"). I've tried deleting the scheduled item and re-creating; didn't help.
Is there some startup item SuperDuper needs?
I could re-install it if that would help; will this retain existing backup scripts?
Is there an authorization step which might have gotten un-memorized by the thrashing, and if so would there be no notification that that was the problem?

dnanian
10-26-2010, 10:11 AM
Well, it's hard to say since I have no idea what got done here. We don't need a startup item, no - we're running with 'cron', the system scheduler. Did you delete or somehow mess with LaunchServices or Launchctl?

Irl
10-26-2010, 10:22 AM
Full history:
While starting up, started an application (Amadeus Pro) which tries to allocate a large scratch memory area. (This may be irrelevant.) System hung, Finder didn't start. Tried quitting the Finder, didn't help. Deleted all of my "login items" in the hope that something there was causing the problem; didn't help. Started TechToolPro, couldn't unmount either system or user volume (files were allegedly open). Rebooted from the eDisk which TTP sets up, still couldn't unmount. Used TTP to "fix files" (couldn't "fix volume" since that requires unmounting), that made the system volume unmountable. Unmounted it, ran "repair permissions" from Disk Utility, noticed that one Finder-related file (I believe it was its .plist file) was listed as having wrong permissions which was then fixed. At that point the system would start up normally. I had foolishly neglected to make a list of my startup items so I restored the ones I remembered or was reminded of by perusing the list of installed applications.
After all of that, the problem with SD appeared. I noticed it because the overnightly backups failed to run the night after the disaster recovery, so I tried running manually, with the failure I reported in my original post. These normally run from an account which does not have admin privileges (my non-computer-geek wife stays logged in overnight). Note that I can run a backup (while logged in as her) from the main window, just not the "scheduled backups" one; thus scheduled backups don't run either.
Is there a process important to SD which I could verify is running normally in the Activity Monitor?

dnanian
10-26-2010, 10:33 AM
It would be the launchctl daemon. Maybe the right thing to do here is to reinstall OSX (archive-and-install equivalent, if you're running Snow Leopard it's just a reinstall) to 'fix' the system and see if that corrects things, Irl.

Irl
10-26-2010, 09:51 PM
The launchd process is live; I assume that is the target of launchctl, rather than there being a separate launchctl process.
I fixed the problem as follows:
deleted the com.blacey.Superduper!.plist file (why does this have such an odd company name as "blacey"? made it hard to find.)
Ran Superduper, it asked for my authentication info and also registration info, which I copied from the receipt.
deleted the old scheduled copies and recreated them
I hope this helps identify what the problem is/was. If there's any further info I can supply that would be of interest let me know. I'll save one of the dead scheduled copies for a while; let me know if there is some way to send it to you if that would be helpful.

dnanian
10-26-2010, 10:00 PM
The plist has nothing to do with scheduling... so what you really did here was delete and recreate your schedule, which you said you already did. Weird.