SuperDuper Scheduling/cron failures

[dnanian]

Cron is not deprecated (see "man cron" - no menton of deprecation): in fact, it's implemented with launchd. Launchd doesn't offer any more flexibility for timer-scheduled events (I had hoped it would, but it doesn't). Rewriting scheduling to use launchd wouldn't really generate any tangible benefits, other than to use "the new shiny". There's just no compelling argument to do so at present.

As far as vi goes, well, navigate to the line you want to remove with the cursor keys, press 'd' twice to delete the line, then ":wq" to write and quit vi. Alternatively, if you uncheck the time part of all your schedules and then use "crontab -r", it'll remove the tab. It'll then get recreated when you turn the schedules on again.

The two daemons - that is, the login one and the 'on mount' one - do entirely different things. One sets up the backup-on-mount environment by initializing the list of volumes, which handles situations like logging in and out of an account where temporary items aren't removed. One actually responds to mount events. They're quite different, even though they call the same program (with different parameters) to do the actual work.

I just don't agree that this stuff is overly complex. Each part is there for a reason... there's an 'automatic run' driver that's used to run a given set of settings for an event (either scheduled, on mount, on button press or any other event), there's a system tool for running on schedule that we leverage (and was there well before launchd, and offers the same functionality with the same limitations), and there's launchd for triggering running on mount.

Each group of settings has its own 'automatic run' driver because they're designed to be modifiable by advanced users on a 'per setting' basis. You need a separate backup-on-mount 'driver' because you don't know where the 'automatic run' driver is when the event fires (and there can be many), nor what settings should be used, and that takes an event ("something mounted") and that determines how to respond to the event, and with what.

Yes, we could put all that not-really-that-related-but-working-together-to-accomplish-a-task logic in one giant centrally-located tool, and eliminate the user-modifiable part, but that gets rid of useful functionality (to a small number of users, of course), and doesn't really 'fix' any problem (and, it couples things closer than I would want). I mean, it'd be like taking every command-line tool in Unix that deals with 'files' and combining them into one huge tool with a zillion parameters to 'streamline maintenance'. They tried that in CPM: it was called 'pip', and it was a huge mistake.

(As an aside, this stuff is done in AppleScript, rather than in Objective-C, to show how you can use AppleScript to accomplish system-level things in OS X. Personally, AppleScript drives me crazy—I can't tell you how much I struggled with it when I wrote these two parts—but it's more understandable than the various shell script languages to most users, and was the right tool for the job.)

Anyway, things sometimes feel 'off' when you haven't gone through the process and history of creation. Does that mean everything in SuperDuper! is perfect? No - but there are usually good reasons to do what we've done...