Just a quick post to let you know how things are going with SuperDuper! and the upcoming v2.6.2 (no release date yet, so don't ask—hence this post). So far, we've:
- Implemented a fix for the problem where we don't preserve compression under Snow Leopard
- Ensured that extra data is no longer copied with back-to-back Smart Updates (as expected, a side-effect of the compression issue)
- Resolved the various other issues mentioned in the last post (although we haven't come up with a fix for the scheduling/settings issue yet)
These fixes have been in external testing for over a week, and the feedback has been excellent so far.
Since we hate releasing updates that have nothing but "fixes" in them, in addition to the above, we've made some changes that significantly speed up the speed of copying, with both Smart Updates and full copies.
In our internal tests, confirmed by our external testers, copying under Leopard and Snow Leopard (with larger data sets) is up to (wait for it) three times faster, especially with fast destination devices.
Needless to say, both of these changes involved "cracking open the cloner", which requires significantly more testing than a tweak to the UI or some "simple" changes to higher level aspects of the copying process, but progress is very good and we're looking forward to getting this into your hands as soon as we (and our external testers) are satisfied with it.
Note that I'll be at C4 this weekend, so support might be a bit slower than usual from Friday until Monday. If you're at C4 too, say Hi!
Well, a week has gone by, and 2.6.1 has been downloaded and run by an awful lot of you. It seems to be working well, too—which isn't to say it's perfect so, once again, no unicorn.
Here's what we're working on right now.
Individual file compression under Snow Leopard is not maintained on the backup
This kind of caught us by surprise, frankly. When we checked our copy results, we found that the sizes of files were the same on source and destination, and assumed the files were, indeed, being copied with compression.
Nothing like an assumption to make one feel like an ass. Or an umption. Whatever.
Anyway, what's happening is the OS is hiding the compression from us... and we didn't realize it. For the nerdly among us, here's some terminal commands and output that you'll find interesting:
$ ls -l /Applications/iCal.app/Contents/MacOS/
-rwxr-xr-x 1 root wheel 9123088 Jul 16 03:42 iCal
$ cp /Applications/iCal.app/Contents/MacOS/iCal ~/iCal
$ ls -la ~/iCal
-rwxr-xr-x 1 taiko taiko 9123088 Sep 4 17:16 /Users/taiko/iCal
OK! So, I copied a file, and as you can see, the size of the file is the same when I started and ended: 9123088. This is what you'd see with SuperDuper!, too (except with the ownership and stuff preserved). So, everything's cool, right?
Well, no. At a lower, block level:
$ du /Applications/iCal.app/Contents/MacOS/iCal
6776 /Applications/iCal.app/Contents/MacOS/iCal
$ du ~/iCal
17824 /Users/taiko/iCal
Well, look at that: iCal, despite being copied with a system tool, is now nearly 3x the size in blocks after being copied, but the same size at a high level.
Great.
Needless to say, that's why we got confused. The sizes were the same. But they weren't... and you could only tell by looking at the amount of space the files took on the drive, not the file's size.
Note that cp, tar, Finder, etc all behave the same way with this: the file ends up getting expanded. The only one that acts differently, when given special parameters, is ditto, and that's likely because it's used by the installer (which puts these files on the drive in the first place).
We've got a good handle on this, and we're in the process of modifying SuperDuper! to retain the compression in the next update.
Some files get recopied every backup
We're aware that some files (specifically, files in /Applications, /System and /Library) are being recopied each time you back up, which significantly slows down repeated Smart Updates.
Our initial investigation has shown that while we thought this was related to prebinding, this is actually related to the compression issue, above. Specifically, compressed files, when they expand during copying, compare differently with flags and with certain time fields.
We didn't catch this because our confirmation tests didn't use compressed files. We did know that we were recopying files, but due to the fact that the end result was fine, and Snow Leopard shipped four weeks earlier than we expected, we just didn't have time to investigate the problem fully, especially since fixing it would involve the most critical and most time consuming to test part of SuperDuper!—something that we'd frozen many weeks before.
In other words, considering the issue was basically one of performance, we thought it was better to get the update out day-and-date with this known issue, than hold it back for the week or so it would take to investigate and fix (and then however long it took to test, based on what we had to change).
This should also be fixed in the next update.
Slower performance
We've had some reports of slower performance in the new version, which is more than a little weird, since the base-level copy calls are the same. Part of that is due to the re-copying, above, but we're looking into it further to see if there has been a regression, and if so we'll fix it as soon as we confirm and find the cause.
People aren't recreating their schedules
This version of SuperDuper! requires that people recreate their schedules due to some problems reading in parts of the old settings files. Many users aren't doing this, so we're trying to improve our error handling to detect and force the schedule to be recreated, rather than just asking people to do so.
UTF8 encoded URLs in AppleScript bite me again
So I'm an idiot. I can't tell you how many times I've attacked this specific problem in AppleScript, but I blew it again in the schedule driver in some cases, so drive names with some unusual characters (accents, etc) won't always run when scheduled.
Again.
I've already fixed this problem and it should be in the next update. It's been tested with both regular Unicode characters (e.g. ) and composed sequences (e.g. é). Note, though, that I haven't managed to get AppleScript to work with a drive named using the Alpha character (α) with backup-on-mount (reported by Glenn—thanks), because Finder fails when I try to use that character in a built-up path. Anyone who's awesome with this stuff in AppleScript please contact me if you have any ideas, because I'm fresh out.
Japanese users and backslashes
Back in the days of Panther, there was a weird bug where backslashes () didn't work in AppleScripts, because they were confused with the Yen symbol when you were in Japanese language mode.
That was supposedly fixed in the compiler back then... but in Snow Leopard, the problem seems to be back (it works properly in the Script Editor but not in the command-line compiler osascript), and I used some backslashes in the updated schedule driver. That's been fixed as well—thanks to Tohru for reporting the problem.
I think that just about covers the issues we're working on right now at a high priority... back to it.
