View Single Post
  #10  
Old 03-29-2010, 12:46 AM
diamondsw diamondsw is offline
Registered User
 
Join Date: Oct 2009
Posts: 16
Okay, looks like I will post again. I just deleted all of my scheduled copies due to problems with last night's backup (see my other thread), and SuperDuper still left stray entries in crontab. Twice I've tried to delete scheduled backups, and twice SuperDuper has failed to clean up its own mess.

To recap, fixing this requires:
  • Seeing that there is UNIX mail from the failed cron process, and knowing how to read it.
  • Knowing cron exists, even though nothing else on the system uses it and it is deprecated - specifically for application-level use.
  • Knowing how to use vi or override the EDITOR variable to remove the bogus entry.
Fixing this with launchd would require:
  • Delete a plist in a standard location.
If this system worked and was bug-free, you could argue all of this is moot - except it's not. It's a broken feature, but I've seen no intention of fixing it. There's clearly a bug in how SuperDuper interacts with cron, and it's compounded by an arcane system that makes it very difficult to fix. It bears repeating, Apple says specifically that applications should not be using cron:

Quote:
Because installing cron jobs requires modifying a shared resource (the crontab file), you should not programmatically add a cron job.
It doesn't matter to me anymore; I've given up on SuperDuper being able to schedule jobs properly. If I can't trust something as crucial as backups, then they're worthless to me. I'll script it myself (even though the AppleScript dictionary is still partially broken) - at least then I know what the bugs are and can fix them, and I'll let SuperDuper does what it does best - copy files.
Reply With Quote