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.
