Shirt Pocket Discussions  
    Home netTunes launchTunes SuperDuper! Buy Now Support Discussions About Shirt Pocket    

Go Back   Shirt Pocket Discussions > SuperDuper! > General

 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #3  
Old 03-14-2010, 05:36 AM
diamondsw diamondsw is offline
Registered User
 
Join Date: Oct 2009
Posts: 16
Quote:
Originally Posted by dnanian View Post
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?

Quote:
Originally Posted by dnanian View Post
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.

Quote:
Originally Posted by dnanian View Post
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.

Quote:
Originally Posted by dnanian View Post
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.

Quote:
Originally Posted by dnanian View Post
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.

Quote:
Originally Posted by dnanian View Post
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.

Last edited by diamondsw; 03-14-2010 at 05:40 AM.
Reply With Quote
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Failed to enable ownership on SuperDuper BackUp Anne West General 1 02-03-2010 01:38 PM
Superduper fails after upgrade to Snow Leopard josephc General 2 09-12-2009 10:18 PM
Needed: Time Machine and SuperDuper guidance kapalama General 7 08-13-2009 07:55 AM
New to Mac and to SuperDuper - Need a little help MikeG General 15 02-14-2008 10:35 PM
A word of praise for SuperDuper! MMM General 3 06-21-2006 10:08 PM


All times are GMT -4. The time now is 02:35 AM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.