View Single Post
Old 03-13-2010, 04:50 PM
diamondsw diamondsw is offline
Registered User
Join Date: Oct 2009
Posts: 16
SuperDuper Scheduling/cron failures

First off, a scheduled copy that I previously deleted is still attempting to run. Nightly, I get messages in my UNIX mailbox (nothing I ever would have noticed, except for a stray line in the terminal one day) complaining that cron can't find a file, and points to my old saved settings that had been scheduled. I've searched my entire system for cron files that might be related to this and found nothing.

  • First of all, I'd say don't use cron. Anything it can do launchd can do better, and the files are in standard user-visible locations and more readable.
  • If you're still using cron, please check for stray entries such as the one that I'm seeing. I'd delete it myself except I can't find the thing.

In researching this, I was a bit appalled at the potential for breakage in the "backup-on-mount" system.
  • Two different launchd scripts watch for either login or /Volumes events
  • They launch an alias in the home directory that's to a script located inside the SuperDuper application bundle
  • The script does some diskinfo magic and jury-rigs some plists for Tiger users, seemingly to get a list of what disks are attached.
  • Script then iterates through all scheduled copies in the user's home folder looking for ones that run on mount, and if they contain the newly mounted drive name. What if I have two backup-on-mount destinations called "Backup" and "Backup 2"?
  • If found, environment variables are set and a new application (which appears to be inside the scheduled copy package) is launched which will launch SuperDuper and the scheduled copy. Not sure why an app is needed for this; just script it since you're already in AppleScript.
It requires two launchd scripts, an alias to resolve, is dependent on the workings of a command-line program which has changed format in the past, assumes disk layout is in a standard state (e.g. home directory hasn't moved), then is dependent on the internal XML of the scheduled copies, assumes disk names won't contain other disk names, sets an environment variable that only this one app knows, and fires the app.

launchd (2) -> alias -> AppleScript -> diskinfo (10.4 vs 10.5) -> iterate through folder (hope it didn't move, parse XML) -> set environment variable -> open a buried ".app" -> open
  • Use a single launchd daemon that runs on either login or on /Volumes changing.
  • Use a single AppleScript or compiled daemon in a known location (/usr/local/bin is traditional), which at the end calls SuperDuper directly with the appropriate parameters.

My attempts at replacing this system have been difficult, as SuperDuper's "error" keyword in AppleScript conflicts with the language itself and can't be used:

status (idle/running/done/error, r/o) : Returns SuperDuper's current status
"Error" is reserved by the AppleScript language:

Signals an error in a script.
error [ errorMessage ] [ number errorNumber ]
***[ partial resultresultList ]
***[ from offendingObject ] [ to expectedType ]
I get as far as checking volume mounts, ensuring the necessary volumes are there, put up a brief message, and get all the way into telling SuperDuper to copy - and then get stuck on the error status. So instead of checking for an error you have to check all other statuses and from that figure out there was an error. Kludgy.

  • Use something not reserved by AppleScript.
Reply With Quote