I've been running Catalina under as a Parallels VM and haven't yet requested a trial Key for that, but with the official release approaching I thought I'd ask:
Any known issues with QRecall under Catalina?

Steven J Gold wrote:Any known issues with QRecall under Catalina?

Other than "it won't work at all," things are looking pretty good.

But seriously, a Catalina compatible version is in the works. It's been a long road because Catalina breaks many basic assumptions about the filesystem and volumes.

In a nutshell, Catalina splits a bootable macOS volume into two volumes: a read-only system volume and a read-write "data" volume, where all of the modifiable files get stored. It then uses a new filesystem construct (called a "firm" link) to blend the contents of the two together so it appears to be a single volume.

Since the idea of backup software is to capture the files you'd want to restore, the new QRecall captures only the "data" half of a system/data volume pair. This actually accomplishes a long-term goal of QRecall, which was to isolate just the files you need to restore a bootable volume and not capture any of the immutable system files (that the OS installer would simply overwrite anyway).

While conceptually simple, this has resulted in large number of adjustments to the software. QRecall has always been "device" oriented, capturing and restoring all of the physical files on a single volume. So the idea that all of the files on a volume are, well, on that volume is deeply ingrained in the software.

But we have made a lot of progress. I can't guarantee it will be ready to for the Catalina release, but it should be close. I hope to have a beta within another week or so.

There is now a Catalina (macOS 10.15) compatible version of QRecall available.

If you are already running Catalina, QRecall will suggest this update automatically. If you are not yet running Catalina you can download it manually, although you won't (shouldn't) notice any difference.

Please read the release notes as it contains important information about how system volume captures and restores have changed.

I just upgraded my iMac to Catalina, and the next time I ran QRecall, it prompted me to download the Catalina-compatible version, so that was good. It seems to be working, but I did run into one issue I didn't expect. The release notes did warn that after a Catalina upgrade, with APFS volumes, QRecall would see your drive as a new volume with the same name, and you could use the "Combine Items" function to fix that. When I ran my first home folder recapture action after upgrading, I could quickly see that it was recapturing EVERYTHING, so I decided to let it run and I went to bed. I checked it the next morning, and it hadn't finished. There was a dialog on the screen saying '"QRecallScheduler" would like to access files in your Documents folder.' with buttons for "Don't Allow" and "OK". The recapture had apparently been paused for hours waiting for me to answer the dialog. I clicked the OK button and left the Mac to finish the recapture. About 20 hours after I started the action, I finally got around to looking at it again, and it had once again paused, with a similar dialog. I think this time it was asking about the Desktop folder, but I'm no longer certain. I hit the OK button again, and the next time I checked, about 4 hours later, the recapture had completed with no errors.

So those two requests for access were unexpected, and caused a significant delay. I'm hoping this was a one-time thing, and the problem won't recur.

I had one other small issue, which may affect some people. My backup drive is bootable, and I was storing my archive files in a folder called "QRecall Archives" at the top level of the backup drive. I also upgraded my backup drive (which was also an APFS volume) to Catalina, and when I did so, it didn't like where my archives were stored. They got moved to the "Relocated Items" folder on my desktop. I moved them to the /Users/Shared folder, and adjusted my actions to match, and now everyone is happy again.

By the way, when I moved the archives, they appeared to copy rather than move. I had a copy in /Users/Shared, and I had another copy in the "Relocated Items" folder. My archives were large enough that this shouldn't have been possible -- I didn't have enough free space on the drive to maintain two copies of the archive files. When I deleted the copies in the Relocated Items folder, I checked the free space on the disk and noticed that it didn't change. Apparently the duplicate copies never occupied any space. I'm guessing this is one of the new tricks that APFS provides. Snapshotting maybe? It may have been possible in Mojave and earlier, but if so, I hadn't noticed until now.

-- Bruce

Bruce Giles wrote:So those two requests for access were unexpected, and caused a significant delay. I'm hoping this was a one-time thing, and the problem won't recur.

It shouldn't reoccur, at least for the questions you've already answered. But I'm actually surprised it interfered with the capture process. It shouldn't; the QRecallHelper and QRecallScheduler processes are largely independent of one another and blocking the scheduler shouldn't prevent capture from running unabated.

And, as you might guess, this is a security feature and there's no way to disable or get around it. So during your initial upgrade you'll just need to answer "OK" to any access questions.

By the way, when I moved the archives, they appeared to copy rather than move. I had a copy in /Users/Shared, and I had another copy in the "Relocated Items" folder. My archives were large enough that this shouldn't have been possible -- I didn't have enough free space on the drive to maintain two copies of the archive files. When I deleted the copies in the Relocated Items folder, I checked the free space on the disk and noticed that it didn't change. Apparently the duplicate copies never occupied any space. I'm guessing this is one of the new tricks that APFS provides.

Yes, this is an APFS trick. In APFS, copying a file (by default) creates a "clone" of that file—both files share the same set of data blocks. A lazy "copy-on-write" feature makes the actual copy, on a block by block basis, should you modify either of the files.