Blog

ccc, yosemite

Will CCC work with [insert Apple's pre-release OS here]?

by Mike | June 4, 2014

Will CCC work with [insert Apple's pre-release OS here]?

Every time Apple makes a new operating system available to developers, we spend several weeks evaluating CCC on that new OS. We look for changes to the features and behavior of the HFS+ filesystem, how the new OS supports (or fails to support) network filesystems, changes to the boot process, changes to support for USB, Firewire, and Thunderbolt -- and a bunch of other things. If nothing has changed and no problems are encountered, the process takes a couple weeks. Realistically, it takes at least three weeks to complete qualification, and in the worst case scenario (e.g. Snow Leopard and Lion), it takes several months to fix problems or add support for new OS and filesystem features. It's a lot of work -- a lot more than the average developer would face when a new OS is released because our software relies so heavily on filesystem functionality and operating system behavior (especially stuff that is poorly documented or not documented at all, like the Recovery HD). We clone the OS, and when Apple ships a new OS, we'd better be doing that correctly.

Because the qualification process consumes so much of our time, we approach it in two phases:

Evaluate functionality on the Developer Preview. Identify major problems and develop a strategy and timeline to resolve them. As problems are addressed, we may post betas for external evaluation.
When the GM is announced and delivered to developers, we complete final qualification. Our final product is ready when the "Golden Master" is made available to customers on the AppStore.

It would be foolish for us to complete a thorough qualification on the Developer Preview because a) the Developer Preview is usually quite buggy and Apple's bugs waste my time and b) qualification on the Developer Preview has no relevance to the final product -- we would have to repeat qualification as soon as the Golden Master is posted. Based on experience with past OS X releases, cloning software should not be used to clone new OSes until it has actually been tested on the new OS. While that seems like a common-sense statement, it's apparently not a common practice. That's our policy, though, and that's why you get a dialog that says CCC isn't qualified on Yosemite.

Last year, I had time set aside to produce a beta that would work on Mavericks shortly after the Developer Preview was made available. The announcement of Mavericks was highly anticipated, so I could budget my time really well. This year, Yosemite came with less warning. As a result, I'm in the middle of other work that can't be set aside to start Yosemite evaluation. I plan to start evaluating Yosemite in a few weeks, though, and I hope to provide a beta once any surprises are sorted out.

For every major release of OS X since 10.3, we have had a qualified version of CCC ready the moment that Apple shipped the... Read More

Design, Philosophy

Thoughts about progress indication

by Mike | January 24, 2014

Carbon Copy Cloner has two different methods of providing progress indication, "fast" and "more accurate". "Perfectly smooth progress indication every time" is what many people want, along with an estimate of how long the task will take, but they often don't realize the cost to achieve that for a backup task that copies only items that have changed since a previous backup task.

Fast

If you don't deselect anything from CCC's list of items to be copied, CCC will start copying files immediately. Because CCC has no idea how much data will have to be copied to the destination, it bases progress indication on the number of files that have been processed vs. the number of files reported to exist on the source volume. If you have several really, really large files, progress indication may appear a bit uneven -- the progress bar will move steadily as CCC processes smaller files, but will move very slowly when large files are encountered. People generally want CCC to start copying right away, though, because it's faster to do it that way, and people are impatient.

More accurate

If you have excluded any items from the list of items to be copied, the total number of files on the source volume (which is easy to obtain very quickly) is no longer an accurate measure of how many files will be considered in the backup task. CCC will pre-scan the source volume to get an exact list of the items will be considered for copying. With this list in hand, CCC knows exactly how much data is in the data set that you're copying. With this information, CCC can now provide progress indication based on the amount of data that has already been considered vs. the total data in the data set. This method has its drawbacks as well, if you have several really, really large files that CCC decides are already up to date, the progress bar will jump ahead quite a bit when those files are considered.

Perfectly Smooth Progress Indication Every Time

The only way to achieve perfectly smooth progress indication, and to provide a "time remaining" estimate would be to pre-scan the source and the destination and compare those lists of files to determine not only how much data is in the data set, but also to determine which files are already up to date and which files will need to be copied. This would give a third data point, "total data that needs to be copied", and CCC could use that to determine progress. I have thus far decided against implementing this kind of progress indication because it is impractical. The goal of running CCC is to get your stuff backed up and to do so with as little effect to your productivity as possible. The amount of time that it would take to basically do a dry run of the backup is a significant portion of the time that it would take to actually do the backup (for times that you are updating an existing backup). I don't think I've ever drawn up these numbers before, so I decided to do that this morning. The... Read More

« first
‹ previous
1
2
3
4
5
6
7
8