https://forums.qrecall.com/posts/list/6.page JForum - http://www.jforum.net
The reported error is always that the archive is damaged and needs repair. Disk Utility reports no problems; QRecall repair operations never seem to finish (>12 hours).

This has been observed on two computers so far; neither has been able to successfully back up since Big Sur.]]> https://forums.qrecall.com/posts/preList/2348/5924.page https://forums.qrecall.com/posts/preList/2348/5924.page GMT
Sorry to hear you're having problems. I'm sure there are going to be some edge cases to work out, but I have several computers here running Big Sur and they're all capturing files as I type this.

Next step is to send a diagnostic report and take a look at exactly what those errors are.]]> https://forums.qrecall.com/posts/preList/2348/5925.page https://forums.qrecall.com/posts/preList/2348/5925.page GMT
Thanks for the diagnostic report.

Your logs indicate that there's a corrupt value in the layers.index file. This is an auxiliary index file that summarizes the directory structure of the entire archive.

A reindex of the archive should fix it.

Your logs also show that you started a repair on 11-16 a 12:25. It was canceled about 50 minutes layer, and it promptly stopped at 13:11.

I suspect that starting another repair, and letting it finish, will fix the problem.

If not, please send another diagnostic report after the repair.]]> https://forums.qrecall.com/posts/preList/2348/5929.page https://forums.qrecall.com/posts/preList/2348/5929.page GMT https://forums.qrecall.com/posts/preList/2348/5926.page https://forums.qrecall.com/posts/preList/2348/5926.page GMT
But I'll give the full repair a try and let you know!]]> https://forums.qrecall.com/posts/preList/2348/5930.page https://forums.qrecall.com/posts/preList/2348/5930.page GMT
The next step is to see if it happens again, or to other users.]]> https://forums.qrecall.com/posts/preList/2348/5932.page https://forums.qrecall.com/posts/preList/2348/5932.page GMT
So when I said "other users" ... that was me. :)

I haven't run into this error on any of the hundreds of captures performed by my regular machines running Big Sur.

But ... I just ran into the same error while debugging some new QRecall 3.0 code. So there's probably a Big Sur related glitch lurking somewhere.]]> https://forums.qrecall.com/posts/preList/2348/5936.page https://forums.qrecall.com/posts/preList/2348/5936.page GMT
So there was a problem. It wasn't, technically, specific to Big Sur, but Big Sur is what drove QRecall over the edge.

The [b]layers.index[/b] file stores a compact summary of the directory structure for all of the archive's layers. There was an assumption that a folder wouldn't have more than few hundred subfolders. If a folder has more than 65,000 subfolders, the file would get corrupted, and that's what was happening.

The metadata daemon in Big Sur creates temporary folders inside /private/var/folders (the standard UNIX location for temporary and cached data). But unlike Catalina, the Big Sur version creates a lot of subfolders. And I mean, hundreds of thousands of subfolders?all in a single folder. (It's clearly taking advantage of APFS's hashed directory structure, but it was unexpected behavior.)

So if you happened to capture a volume while the metadata daemon was working particularly hard, there was a possibility that you'd capture a folder with too many subfolders.

The latest version of QRecall (2.2.9), expands the subfolder limit to 4 billion.

Update at your leisure.]]> https://forums.qrecall.com/posts/preList/2348/5955.page https://forums.qrecall.com/posts/preList/2348/5955.page GMT