SuperDuper Scheduling/cron failures

[diamondsw]

Originally Posted by dnanian

Needless to say, SuperDuper!'s scheduling facility is older than launchd, and there's little reason to move from cron to launchd: it doesn't do this kind of thing "better", it's just "newer". (In fact, cron's been around for a very long time, and is well known and tested.)

It's also deprecated and could be removed entirely any time. Launchd is much more flexible, and in my opinion (but just an opinion) more readable and readily accessible than cron. Cron's advantage is it's familiar... to people who know cron. I thought I knew cron, but vixie-cron is quite a bit different from the traditional editing of /etc/crontab.

I'd have also thought that with the backup-on-mount system using launchd and Applescript, it would make sense for the scheduling system to also use the same framework. What exactly does cron allow SuperDuper to do that launchd does not?

Originally Posted by dnanian

If you want to edit the crontab, you can use "crontab -e" and remove the bad entry... but I don't know how you ended up with a 'stray'.

SuperDuper is the only thing accessing it. So, I don't know what to tell you.

Originally Posted by dnanian

As far as "Backup on Mount" goes, I'm well aware of how it works, and I think you'll find it's less fragile than you imply. To make things easy to remove, all executables (etc) are kept in user accessible areas - /usr/local/bin, while traditional, is not removed when the application is removed (and the alias is updated to point at the right place each launch).

I'd hope you know how it works! :-) Still, I can't help but think that there's got to be a fair amount of code in there devoted to keeping the various parts of that working and checking for errors that wouldn't necessarily be required with a simpler setup. It's an awful lot of glue to accomplish:

1. Check for a new mount.
2. Check if a backup script references it.
3. Run backup script(s).

I suppose when you get down to it, the things I don't understand are the need for two launchd agents instead of one, and the opaque ".app" that starts things rather than just scripting SuperDuper directly. The alias I'm more comfortable with, as I can see that gives a stable path for the launchd agent and alleviates the concerns about moving SuperDuper.

Originally Posted by dnanian

Two destination called "Backup" and "Backup 2" aren't a problem, because the actual full volume name is checked once a quick pass is made to subset the settings being tested.

Good to know, thanks.

Originally Posted by dnanian

And we don't duplicate the functionality in the schedule driver because, well, why maintain two executables that do the same thing? Also, we can't use one launchd daemon: it doesn't work properly in all versions of OSX.

The devil's advocate in me says, then why maintain the multitude of pieces that currently backup on mount and schedule copies? There are so many bits of Applescript, stub applications, and command line utilities, whereas I'd think Launchd could handle the events, and at most a single daemon or script could handle passing control to the main app. I know it's grown over time - especially working around OS differences - but it still just seems overwrought.

I suppose when you get down to it, there's no arguing with results - the only issue I have is this phantom cron entry; backups run just fine - and your user base would likely agree that all is well. Something just feels off, and when I see that many pieces, I naturally worry about breakage. The more complex any system is, the more likely it is that something can fail. Of course, given your intimate work with filesystems, you know about that with far, far more experience than I - I've read the travails on your blog.

Originally Posted by dnanian

Alas, I know about the "error" thing - it's a known, logged issue (you're the first person other than me to notice, so kudos).

Heh, pretty sure I reported this one back in the day (2.0 era) when I first created my own scheduling script. I'd still use it, but my backup routine is now much more based on Time Machine for continuous backup, and backup-on-mount for occasional bulk backups to offline storage.