View Full Version : Will SuperDuper work with Mac OS 10.8, Mountain Lion?

06-13-2012, 03:08 PM

1. Will SuperDuper work with Mac OS 10.8, Mountain Lion?

At around 1 hr or so into WWDC 2012 Keynote Video, Apple talks about Power Nap feature of Mountain Lion, 10.8…

2. I remember hearing that SuperDuper! doesn't like any apps running during Smart Update or any kind of Copy, so does that mean that SD users would have to Disable Power Nap whenever SuperDuper! is running?

3. Can Power Nap be Scheduled in 10.8 so that it doesn't interfere with SuperDuper! and vs.?!

I understand that as of now, 6/13/12 you might still be under NDA as far as 10.8, but I and all my friends who use SuperDuper! can't wait to hear the good news that SuperDuper! will always ROCK right alongside Time Machine and ALL Future Mac OS versions!!!

Here is the latest example of SuperDuper! SAVING THE DAY!!!

A friend of mine was one of those affected Thunderbolt Software Update 1.2, which plaguing MacBook Pros with kernel panics as per MacFixIt - CNET Reviews http://j.mp/KCkdB4 None of the Solutions in that article worked!!!! Neither did Starting up from SuperDuper! Hard Drive in order to Apply the Combo Update! The Error stated:

Mac OS X Updated Combined can't be installed on this disk. You can only install this software on teh disk that is running Mac OS X.

Luckily, my friend is a SuperDuper! user, and he had a 3 AM SmartUpdate as of that morning, 6/12/12! So I told him to run that Smart Update in Reverse in order to Revert! It WORKED!!! He was able to Smart Update his Internal HD from SuperDuper! Clone!

Let's hope that Apple's Combo Update or whatever will fix that issue, but… If it wasn't for SuperDuper!, my friend would have been on the phone with Apple Care for a while, or worse, had to drive to the Genius Bar with his iMac...! Instead, in about 15 minutes, he was back to normal…

Thanks Dave!

06-13-2012, 03:14 PM
Can't comment on Mountain Lion, except to say it's always our goal to work with new OS versions as quickly as we can ...sorry! But I'm glad to hear SuperDuper worked well for your friends!

06-13-2012, 03:26 PM
I understand about NDA = No Comment!

I am looking forward to the Official YES from you, as I am sure is the case with all your grateful customers, who, like me, will probably have to hold of on their OS 10.8, Mountain Lion, Update until SuperDuper! Officially supports that OS!!!

Thanks for your almost Instant Reply! Stellar Suport as usual!

07-25-2012, 01:52 AM
So far, it's not working at all well. Takes 10-15s to launch, changing drives takes another 5-10s. So on and so forth. I'm running the GM of Mountain Lion and SuperDuper! is effectively unusable. I'll be switching to another clone program if these issues aren't fixed quickly. With no update in over a year (?) and no sign that devs have a seed copy of 10.8 to work on changes ahead of the game, I'm not encouraged.

07-25-2012, 07:32 AM
Imagine, some developers don't talk about what they have, and adhere to their NDAs. Crazy, I know!

07-25-2012, 11:47 AM
Hopefully you've seen that SuperDuper! 2.7 is now out. I discuss some of the new stuff at the Shirt Pocket blog (http://www.shirt-pocket.com/blog).

Sorry that we had to keep things quiet. I really do try to respect things we agree to.

07-25-2012, 01:38 PM
Imagine, some developers don't talk about what they have, and adhere to their NDAs. Crazy, I know!

Does the NDA actually cover you saying that you are working on an update to support the new OS? Apple obviously announced 10.8 in public, so I'm not sure how an NDA could prevent you from discussing its existence and that you are working with it. You couldn't discuss some of the technical details you've written about in your 2.7 blog post, but you wouldn't need to.

It would go a long way to calm customer nerves to say definitively, "We have been working on and will have an update ready for Apple's latest OS update when it is released". Is that against the NDA? This is an honest question, as it seems like you're actually hurting your business by not giving even the most basic info. Granted, impatient people who say they're going to jump ship because you haven't released the update for them to use during the OS beta are pretty silly, but why even court those discussions?

All that said, we've been on version 2 for quite a while now and competitors are adding new features/options at a pretty quick pace. Is there a version 3 on the horizon, or is that still a long way off?

07-25-2012, 01:47 PM
It's pretty clear, given our history, that we support new OS versions. When someone asks whether SD! works with Mountain Lion, I can't say until release, not only because of the NDA, but because Mountain Lion isn't done until it's on the market. Even the GM can change before it's posted to users.

So, we're conservative about what we say.

If you feel that adding features/options at a "pretty quick pace" is a good idea, SD! may not be the product for you. Which isn't to say we're not working on various future versions. Just that our cadence is deliberately slow and methodical...and, frankly, adding a lot of "features and options" is not likely.

Improving things with every release, though? Adding truly useful things that are improve operation and/or functionality for the vast majority of users? We're all over that.

07-25-2012, 03:44 PM
Thanks for the quick reply. That makes sense regarding the moving target of a prerelease OS.

As far as your comments on adding new features quickly, they seem a bit defensive. Of course I didn't mean to say that I want SD! to carelessly add a ton of new features just to do it. I also wouldn't say that the competition is careless with their improvements or that Shirt-Pocket has a monopoly on "truly useful" functionality ideas.

I suppose what I meant with "pretty quick" was in relation to SD!'s seemingly glacial pace in terms of user experience improvements. I am a long time customer who has been using and recommending SD! for years, and to me, it seems to have stagnated, which is why I asked about a bigger version jump than just another point release. The basic UI of version 2 is almost 7 years old, which is an eternity in software time.

Please know that I use SD! all the time and love it. The existing feature set works, SD! serves it's main purpose well, and I'm not meaning to attack you or SD!. I'd just like to see the product improve and grow a bit. I know and appreciate that there have been many improvements behind the scenes, but little UI and UX issues have been around for years, so it's interesting when I see "truly useful" features listed elsewhere.

07-25-2012, 03:57 PM
There's no lack of ideas for improvements to SD!'s UI, believe me (which isn't to say the existing UI is not good - it is). But it's a matter of finding the time to implement, test (functionality and usability), document, etc, while supporting a large user base (both paid and unpaid) and keeping up with the changes Apple makes with nearly ever major and minor release of the OS.

We have to balance every change, every request, every desire, every day. We ask ourselves if making major UI changes are worth it if, for example, it means we have to stop supporting users before 10.6, or 10.7. Do we spend time investigating "Power Nap", or do we make the window do cool things with Core Animation? Or, should we come up with cool ways for the cloning process to handle complex Smart Update cases that currently might fill the drive, while maintaining a one-pass approach? Which change will benefit users the most?

They're hard choices that can be frustrating...

07-27-2012, 02:18 PM
I in no way think the UI of SD! needs fancy Core Animation effects. I was referring to more pure functionality that would make it easier to use. I think you read my mind in regards to things like Power Nap (operations during sleep) and better Smart Updates in low space situations. Those are 2 of my biggest gripes with SD!, but it seems like the Smart Update issue has been around for a very long time. If it fails because of that (which it does even if I have 30GB free sometimes due to large folders), the only message as to why it failed is in the log and even then it's not granular at all. Most users have no idea what a log even is and they can be intimidating to non-technical users, so error messaging could use some improvement. Even better, why can't SD! determine this is going to happen ahead of time and use a different method so there isn't an error to begin with? If you're always copying instead of moving on the destination, why can't SD! delete files on the destination that don't exist in the source folder before copying files from source?

Anyway, I think we're mostly on the same page. My main, original point was that despite welcome improvements on the behind-the-scenes cloning side of things the rest of the app has remained nearly the same for quite a long time, even though as you said, there are lots of possibilities for improvements and useful feature additions. I'm looking forward to seeing what you have in store for version 3.

Thanks for all your hard work!

07-27-2012, 04:07 PM
Think about what's necessary to delete before copy - and what danger that can cause - and you'll understand why we don't do that.

Power Nap operation, by the way, is only available to Apple at present.

08-01-2012, 06:04 PM
From what I've seen in the log, I assume SD! goes folder by folder and copies everything that's new and then deletes any files that aren't on the source in that folder. Unless I'm missing something, it doesn't copy files from one folder to another, correct? I guess I'm not seeing the danger of deleting those same files before the copy action vs after. You're trying to get the destination to mirror the source, so why does it matter on a per folder level whether you delete files that don't exist on the source in that folder, even if the action is interrupted?

Thanks for the info on Power Nap. I just read some more on it and was curious if there was an API for third party developers. Hopefully soon, although I don't have a supported computer yet anyway.

08-01-2012, 06:08 PM
The problem is that you're not dealing with backups sets. Your backup has a single copy of the files.

If you delete first, and then find that the files are unreadable on the source (say during a move/rename), then you have lost the only good files on the destination - all of them. A source drive failure basically means everything is lost.

Acting on encounter means you minimize this possibility (and some ideas we have for the future give you the best of both worlds).

08-01-2012, 06:17 PM
Thanks for the explanation, that's a good point and makes sense. Still, I thought you copied/deleted folder by folder, so wouldn't the issue be the same? If I move half the files from folder A to folder B, don't you make folder A a perfect mirror first by deleting the files from destination A and then copying them from source B to destination B? Or does SD! do all deletions at the very end of the entire process?

Also, glad to hear a better solution is in the works (hopefully in the near future).

08-01-2012, 06:24 PM
We're acting on encounter, pruning on folder exit.

Can't promise "near future". Been in the works for a while...it's a tad tricky, where you can read "tad" as "understatement".

08-01-2012, 06:36 PM
So then isn't my description correct? As it currently works, files would be deleted from destination A and only exist in source B. If they are unreadable/corrupt in source B, the only good copy of the file would have been lost when you pruned destination A. Isn't that the exact same danger you cited?

I know I'm oversimplifying things. I appreciate how difficult proper backup is and that you're taking the time to make sure it works as well as it should.

08-01-2012, 06:41 PM
I'm not trying to argue, so I apologize if it comes across that way. I'm trying to understand better so that I can possibly help myself some with different file management tactics.

08-01-2012, 06:45 PM
No, it's not correct - the order is more randomized (although not really), and it's more likely that the "good" files will be left on the drive (which is why you're running out of space in some situations).

08-01-2012, 06:56 PM
So the same danger does exist, but in far fewer situations instead of possibly every move/rename situation that would happen if you delete first?

I know you're dealing with an insane number of files, but this all makes me think of how Dropbox does deduplication (I think that's the right term). If I move a file, it's not deleted and recopied on the server. I assume though that a local system like that would require a much larger destination drive which would negate the problems I'm having anyway. ;)

08-01-2012, 07:12 PM
Yes - far fewer. And dropbox is a totally different thing, yeah.

Dropbox is working with a tiny number of files in comparison. Sure, we could calculate checksums and compare every file and determine the totally optimal set of operations. And your regular backup would take much, much longer. (Much.)

We have to balance all this stuff. I know it can be frustrating in some rare situations. But those situations are rare, even though they happen to you...

08-01-2012, 09:19 PM
Understood. And again, thanks for taking the time to explain.

09-13-2013, 05:52 PM
Dave, it's Friday, September 13, 2013, and I already did my Mac OS 10.8.4 to 10.8.5 Upgrade!

Thus far I don't see any problems. I will run my usual SD Schedule later today! I assume that it will be a non-event, no problems either!

I assume it's too early to be asking you about the next Mac OS, Mavericks, given your usual NDA Disclaimers! You will probably have some statement about that on your Site's Homepage after that OS is Officially Available, and NDA doesn't apply anymore, right?!

Otherwise, just a Quick Hello and Public Thank You for the SuperDuper = Peace Of Mind!

09-13-2013, 09:44 PM
Should be fine with 10.8.5. And, no - can't comment on Mavericks...

09-15-2013, 05:36 PM
Hiya, Dave!

can't comment on Mavericks...

If you can say, just wondering if you're intending to post Mavericks-related news/announcements on the Shirt Pocket Watch (http://www.shirt-pocket.com/blog/) blog?

09-15-2013, 06:25 PM
When the time comes.