Author |
Message |
3 years ago
|
![[Up]](https://forums.qrecall.com/templates/default/images/icon_up.gif)
#1
|
David Ramsey
Joined: May 5, 2012
Messages: 51
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.
|
|
![](https://forums.qrecall.com/templates/default/images/spacer.gif) |
3 years ago
|
![[Up]](https://forums.qrecall.com/templates/default/images/icon_up.gif)
#2
|
James Bucanek
Joined: Feb 14, 2007
Messages: 1568
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 - |
|
![](https://forums.qrecall.com/templates/default/images/spacer.gif) |
3 years ago
|
![[Up]](https://forums.qrecall.com/templates/default/images/icon_up.gif)
#3
|
James Bucanek
Joined: Feb 14, 2007
Messages: 1568
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 - |
|
![](https://forums.qrecall.com/templates/default/images/spacer.gif) |
3 years ago
|
![[Up]](https://forums.qrecall.com/templates/default/images/icon_up.gif)
#4
|
David Ramsey
Joined: May 5, 2012
Messages: 51
Offline
|
Done! Duh...
|
|
![](https://forums.qrecall.com/templates/default/images/spacer.gif) |
3 years ago
|
![[Up]](https://forums.qrecall.com/templates/default/images/icon_up.gif)
#5
|
David Ramsey
Joined: May 5, 2012
Messages: 51
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!
|
|
![](https://forums.qrecall.com/templates/default/images/spacer.gif) |
3 years ago
|
![[Up]](https://forums.qrecall.com/templates/default/images/icon_up.gif)
#6
|
James Bucanek
Joined: Feb 14, 2007
Messages: 1568
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 - |
|
![](https://forums.qrecall.com/templates/default/images/spacer.gif) |
3 years ago
|
![[Up]](https://forums.qrecall.com/templates/default/images/icon_up.gif)
#7
|
James Bucanek
Joined: Feb 14, 2007
Messages: 1568
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.
|
- QRecall Development - |
|
![](https://forums.qrecall.com/templates/default/images/spacer.gif) |
3 years ago
|
![[Up]](https://forums.qrecall.com/templates/default/images/icon_up.gif)
#8
|
James Bucanek
Joined: Feb 14, 2007
Messages: 1568
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 - |
|
![](https://forums.qrecall.com/templates/default/images/spacer.gif) |
|