Shirt Pocket Watch

One of the problems with supporting versions of macOS going back to 10.10 is that it becomes harder and harder to test older versions...and that's complicated further by Apple silicon, since you can't run an Intel VM on Apple silicon...Rosetta won't work.

Unfortunately, in v3.7.3 and v3.7.4, this has caused a problem. It's something we didn't anticipate, and, alas, it caused some minor attribute issues on older OS versions that are fixed in v3.7.5.

These problems will self-correct the next Smart Update, and never put data at risk, but they're embarassing anyway.

What Happened

During the last few months, we'd had a report that the "Date Added" attribute of files wasn't getting updated. We didn't remember exactly why that attribute wasn't copied, and when we checked it under current OS versions it seemed like it could be copied, so we implemented that in our copy engine and distributed that to some external testers.

During that process, we found a way to copy attributes that allowed us to eliminate a read operation. Basically, the fts API has a field that was populated with things we were reading separately, and we changed the copy engine to use those instead.

External testing showed why we didn't copy "Date Added" in the first place: setting it is not supported by some file systems and some versions of macOS. So, before shipping v3.7.3, we backed out that change (with a typo that caused the relase of v3.7.4), but we left in the optimization.

Unfortunately, post-v3.7.4, we received a few reports of folders that had become inacessible without elevating permissions. On investigation, this was due to the optimization: not all versions of macOS populate that field properly, and that was causing the problem.

The Solution

The solution to this was to back out the optimization, which we've done in v3.7.5, released today. Any incorrect attributes will be automatically updated next Smart Update.

Things to Improve

We wanted to turn around v3.7.4 quickly once we found the problem, which we did, but since we were backing out a change (rather than implementing a fix), we didn't put it through a full external test.

That was a mistake, especially since it involved the copy engine. And while it didn't cause any harm as such (save for embarassment), it's something we'll endeavor to not do again.

The Future

This may mean we will have to phase out "new" support of older macOS versions in future releases: beyond the testing problems, it has become hard to even set the "target" version of SuperDuper builds to 10.10.

That wouldn't mean we won't "support" older macOS versions (after all, we offer versions of SuperDuper that work with macOS all the way back to the Power PC days), but it would mean that new versions of SuperDuper may not support as many versions "back" as we'd like.

Have at It

SuperDuper v3.7.5 is available now for auto-upgrade and as a download. Thanks, as always, for your support, reports and for using SuperDuper: we appreciate it.

You know that thing where you put out a release, that fixes two minor crashes, but then a typo causes a different failure?

Well, welcome to SuperDuper! v3.7.3/v3.7.4, the "Can I Have a Do-Over" release.

v3.7.3 was released to correct two rare problems: both of which had to do with launching scheduled copies.

The first was a weird race condition that caused occasional crashes right at launch, but only with scheduled/scripted copies launched without loading settings. It was strange, we couldn't reproduce it internally, but it happened to a few users and we think we've run it down.

The second caused copies to terminate successfully, typically after copying all the data, before running the cleanup phase of the copy operation. This was another one we couldn't reproduce internally, but seems to be related to a singleton that was getting re-initialized in some situations. And if that doesn't mean anything to you, don't worry about it, beacuse it's fixed and all is right with the world.

Of course, all was right with the world, until we released v3.7.3 this morning, and within an hour a user got an error.

Really? Oh, Man...

We thought we were in pretty ideal shape. v3.7.3 had been given to quite a few people over the last month or two, and it was working great both internally and in external testing. But, right after release, a user had a copy error on Catalina, and it was quite weird so we ran it down.

During development, we were doing some investigation into copying of some uncopyable attributes, and at one point we found an optimization that allowed us to skip a read operation, since we already had the data.

But, when implmented, there was an expansion-related mistake in one access to the variable, which caused an error in some rare circumstances.

Although, again, we couldn't reproduce the problem internally (I hate that, since it makes it hard to generate a test case to guard against this kind of thing in the future), we nevertheless ran that to ground quickly after v3.7.3's release (ah, v3.7.3, we never really knew ya), and out the door went v3.7.4.

So there you go! Two quick releases, two small fixes, one panicked change of underwear, and one other fix. A good way to spend a Thursday.

Enjoy!