QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
QRecall 2.2 and Big Sur  XML
Forum Index » Problems and Bugs
Author Message
David Ramsey



Joined: 05-May-12 08:46
Messages: 48
Offline

In general, doesn't seem to work. The backup operation may or may not succeed; if it does, merge and other operations will fail.

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.
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1523
Offline

David,

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.

- QRecall Development -
[Email]
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1523
Offline

David,

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.

- QRecall Development -
[Email]
David Ramsey



Joined: 05-May-12 08:46
Messages: 48
Offline

Done! Duh...
David Ramsey



Joined: 05-May-12 08:46
Messages: 48
Offline

It seems strange that after months of problem-free backups, two separate computers developed identical problems at their first Big Sur backup...

But I'll give the full repair a try and let you know!
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1523
Offline

It might be something to do with Big Sur. Or it might just be a coincidence.

The next step is to see if it happens again, or to other users.

- QRecall Development -
[Email]
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1523
Offline

Update: Probably not a coincidence.

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.

This message was edited 1 time. Last update was at 17-Nov-20 12:12


- QRecall Development -
[Email]
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1523
Offline

David,

So there was a problem. It wasn't, technically, specific to Big Sur, but Big Sur is what drove QRecall over the edge.

The layers.index 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.

- QRecall Development -
[Email]
 
Forum Index » Problems and Bugs
Go to:   
Powered by JForum 2.1.8 © JForum Team