View Full Version : Cloning system while preserving target identity (e.g. DynDNS)

11-23-2009, 10:42 AM
Is there a master thread here to collect facts relevant to cloning a system while preserving the identity of the target machine?

I have a growing number of Macs (the new Mac mini rocks hooked up to a living room monitor, if one has internet but no cable or TV tuner), and I use SD! to clone a master system to each Mac. One wants, however, to avoid overwriting various personality files, updating such clones.

For example, if one uses DynDNS Updater to sync a domain name with the dynamic IP address of each Mac, it is tedious to straighten out the mess after two machines duel for the same domain. One prevents this by not overwriting the folder /usr/local/dyndns/Accounts as I describe in the external thread How to clone OS X without overwriting DynDNS identity (http://dyndnscommunity.com/forum/viewtopic.php?f=8&t=2800).

Is there a site anywhere that catalogs an attempt at a complete list of facts like this? One has to be actively involved, it would be too much to ask for SuperDuper! to provide a default script for this, as the choices are idiosyncratic with each of our peculiar needs.

Some issues are quite standard; we simply risk forgetting some of them without community help. The Computer Name as set in Sharing preferences. The whole "ignore ownership" bit for external disks; if the clone sees a drive the master never sees, this risks getting reset on every clone update. And so forth...

11-23-2009, 10:54 AM
I don't know of any master document of this stuff, no... it would change all the time. But once you figure out what you want to do, you can easily preserve/restore the information in before/after shell scripts.

12-04-2009, 12:05 PM
I've just wasted the past hour, taking the term "Ignore" at its word. "Smart Update" is literally a faster erase-then-copy, which means that "Ignore" never means "leave alone what's there".

Let me repeat my application: My MacBook lives in my office, my Mac mini lives in my living room. There are a few key identity issues I'd like to keep separate, between the two machines, but I don't want to waste half my life repeating software installs and updates separately to the two machines. This seems like a dream, stock application of SuperDuper! Clone one machine to the other, but tell SD! for instance to leave alone the directory "/usr/local/dyndns/Accounts/" and the two machines can continue to have separate DynDNS identities.

But no. "Ignore" instead deletes the named directory, which has the effect of instead crippling the target machine.

So how do I tell my script Clone.dset to neither delete the existing contents of a target directory, nor copy the different contents from source?

(Please don't tell me to handle this with before and after shell scripts.)

12-04-2009, 12:40 PM
You can't. The script selects the files from the source. Those files are then reconciled with the destination using the "During copy" method.

That's why I suggested before/after shell scripts before...

12-06-2009, 04:14 PM
I'm having a bit of cognitive dissonance here. I've also been following recently the release of a new programming language, "go" by several of Google's best and brightest. Many people are in an active debate over their design choices. This isn't "please add this feature" but rather a spirited discussion along the lines of "if you could pick seven tools for your toolbox, what would they be?" There's an art to making a design both simpler and more powerful at the same time.

Now imagine what those seven tools would be if instead they were chosen by lawyers worried about liability.

I've been getting this nagging sense for years that SD! is intentionally limited in its interface for the sole reason of minimizing support issues. For example, I spent good money on an inferior sync program to back up one folder to another, because SD! only backs up volume to volume. How many thousands of dollars did other people like me spend on a redundant application, for the same reason? But SD!'s command line tool SDCopy that carries out the actual copying is able to back up any folder to another folder. What is the rationale for locking users out of this functionalilty?

So if SD! were the "go" language, hoards of people would be observing that if one option besides "ignore" was "preserve" (leave alone existing folder, neither delete nor copy), then the logical reach of SD! scripts (in the sense of possible boolean expressions) would be greatly magnified. And the authors would be very curious to hear this.

Why do I feel you have no interest in fixing this bottleneck on SD!'s reach? It isn't feature creep, it's picking seven tools for maximal utility.

12-06-2009, 04:25 PM
That's a foolish conclusion to draw, frankly.

SD's interface is limited to focus on its purpose, and to cut away anything unnecessary that detracts from that purpose, and to try to make what's there as clear, unambiguous and easy to use as possible. It has nothing to do with minimizing support issues (except, of course, that the closer it follows those goals the less support you'll get along those lines): if I wanted to "minimize support", I wouldn't have come out with this kind of tool at all, since 99% of the support is caused by hardware faults and failures... and I wouldn't spend huge amounts of time, each and every day of the last 5+ years, providing it.