PDA

View Full Version : Smart Updates & Small Changes


cspheres
01-07-2005, 09:42 AM
This is probably a User Philosophical Question.

Booting up in a Secure Clone (Sandbox) Partition offers many proven advantages to isolating & protecting your Macintosh HD OSX baseline, what is the recommended philosophy for minor system level changes like preferences? The general philosophy in the SuperDuper! docs indicate, if you like a change you made on the Secure Clone OSX partition, you need to start up with the Macintosh HD baseline and then implement the permanent change there, followed by Smart Updates to both the (applications & users) Secure Clone and the (all files) Backup HD partitions, so all 3 versions represet the same baseline via SuperDuper! routines/scripts.

Q1. Since SuperDuper! looks at every file when processing a Smart Update, while quite fast it does take some time, could not making small preference changes be quicker if done manually to each of the 3 example partitions, especially if the changes were made with an application like OnyX where change buttons call one or more of their internal Scripts or say with an identical User generated Script for each partition. The saved User time would be about 3X on my system, but it then begs the question about whether or not it would impact Clone integrity for the 3 partition examples, when you want to use SuperDuper! in the traditional manner again?

Not trying to beat the system philosophy of SuperDuper! which is well thought out, I'm just trying to save time, if possible. This question came up while upgrading my system with SuperDuper! where it was utilized as an intergal tool for mapping the multiple HD's and their required Partition sizes, where after finishing with everything I found I had forgotten some minor preference changes and then experienced the time it took to implement them via the recommended Smart Update routines. While waiting for SuperDuper! to finish my idle brain was thinking I could have done this manually much quicker, which prompted me to post this thread.

lol! If I was answering my own question, I would probably respond with "Proceed at your Own Risk" and realize if you are not sure about what you are doing, you get to do it all over again the SuperDuper! way.

cspheres
:) :) :)

dnanian
01-07-2005, 05:14 PM
There are a lot of things you can do here, actually. Note that you can actually sync the Safety Clone *back* to the original drive. (Kiddies -- don't try this unless you know what you're doing.)

The basic deal is that as long as the Safety Clone was created BY SuperDuper!, and you haven't tried to manually create aliases from the original volume to the Sandbox, you can clone back using Smart Update and Backup - all files, and it'll update the original with the changes made on the clone... so, that's a shortcut of sorts...

cspheres
01-08-2005, 04:01 AM
dnanian, thanks for the response. It would be helpful if you could provide an example where the user might manually create an alias/aliases from the Original Volume to a Secure Sandbox Clone, thinking they had done no wrong.
__________
--cspheres

dnanian
01-08-2005, 09:16 AM
An example would be something I do sometimes: installing a new application to the original drive's Applications folder, and then dragging an alias over the the Safety Clone's Applications folder.

The difference is that SuperDuper! creates "symlinks", which is a Unix "alias". The Finder creates an HFS+ "Alias", which is not at all the same, and needs special code for "cloning back" that's not in the current release. So, rather than recognize the fact that we've got a link, we'd end up overwriting the application.

The solution: just install to Sandbox. When you clone "back", the application will be copied to the proper location. (If you're just "updating" an application, that'll work fine, because the "shared" application was created by SuperDuper!, and is the proper type of link.

There are very few similar situations where this might happen (I can't predict everyone's individual use of Finder), but it's something to be aware of.