QRecall Community Forum
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Top Downloads] Top Downloads   [Groups] Back to home page 
[Register] Register /  [Login] Login 

[b16] folder is unreachable? RSS feed
Forum Index » Beta Version
Author Message
Ming-Li Wang


Joined: Jan 12, 2015
Messages: 78
Offline
For two straight weeks my system partition archive needed repair when verified. In both times disk verification showed no error and the repair was successful, but 6 out of the last 7 daily layers are now "incomplete", while 4 from the previous week were incomplete. (Note that I removed those incomplete layers and compacted the archive after the first repair.)

As can be seen from the screenshot below, the repair log indicates there are 4 "unreachable" folders under my system partition "carlosys", including one under my user profile directory tree. The 4 folder serial numbers are the same for each day. Unfortunately I can't tell which folders they are referring to so I can't investigate further.

I'm still on Yosemite (10.10.5), if that matters.

edit: forgot to say, a diag report was sent.

  • [Thumb - Screen Shot 2015-10-10 at 10.36.36.jpg]
 Filename Screen Shot 2015-10-10 at 10.36.36.jpg [Disk] Download
 Description No description given
 Filesize 136 Kbytes
 Downloaded:  1035 time(s)

Ming-Li Wang


Joined: Jan 12, 2015
Messages: 78
Offline
Did a manual capture just now, followed by verification, and sure enough, the verification failed again for the same reason. It's repairing. I'll send another diag. report when it's done.
James Bucanek


Joined: Feb 14, 2007
Messages: 1567
Offline
I have seen this with another archive.

Important question: Is this an archive created with the 2.0 beta, or is this a 1.2.x archive that you started using with 2.0?

- QRecall Development -
[Email]
Ming-Li Wang


Joined: Jan 12, 2015
Messages: 78
Offline
James Bucanek wrote:Important question: Is this an archive created with the 2.0 beta, or is this a 1.2.x archive that you started using with 2.0?

The latter. The date stamp for layer 0 is 2015-01-31, so definitely 1.2.x.
Ming-Li Wang


Joined: Jan 12, 2015
Messages: 78
Offline
Something just came to mind, though I don't know if it bears any significance to the issue.

I have a SSD partition dedicated for my documents, which is mounted at boot as the "Documents" folder under my user profile. As a result, while sys.quanta (the archive at issue) is set up to capture only the system (root) partition, it doesn't backup the contents of the ~/Documents folder, which is backed up separately.

Sys.quanta, however, does show two "volumes" when opened in QRecall: "carlosys" (the name of my system partition) and "Documents", as shown in the attached screenshot below. Note that the size for the "Documents" volume is zero. It really is an empty volume.
  • [Thumb - 2.jpg]
 Filename 2.jpg [Disk] Download
 Description No description given
 Filesize 23 Kbytes
 Downloaded:  1136 time(s)

James Bucanek


Joined: Feb 14, 2007
Messages: 1567
Offline
Ming-Li Wang wrote:The latter. The date stamp for layer 0 is 2015-01-31, so definitely 1.2.x.

This seems to be the problem. I've identified several issues with archives that were originally created with 1.2 and later updated to 2.0.

I'm still investigating, but this problem seems to be related to how volumes are identified in 2.0 vs. 1.x. This disagreement causes newly captured items to migrate into a new directory hierarchy that, in turn, trips a number of internal consistency checks. In your case, a delta directory record (a database record that records changes in a previously captured folder) can only refer to a another directory record that is both (a) in an earlier layer and (b) at the exact same location in the volume/folder hierarchy. The shifting volume identifiers cause the second test to fail, making the inherited directory record "unreachable."

The verify may also report "layer catalog tree" errors, which basically means the folder structure in the index and the folder structure the verify thinks the archive should have aren't identical.

- QRecall Development -
[Email]
Ming-Li Wang


Joined: Jan 12, 2015
Messages: 78
Offline
The verification failed again today with "layer catalog tree" error as you mentioned. It's fine now after reindexing with the newest layer (created last night) intact. I'm going to seal the archive and start a new one for the time being. The old archive would be kept for a while so it would be available for testing if you find a solution.

I keep old system archives to satisfy my occasional curiosity when I want to see how something was done/set back then, and for the rare cases where I want to check an old plist or the like when investigating an issue. Nothing critical. To resuscitate the system, a recent archive suffices.

What worries me are my other archives, which hold my actual "data" and were all created by QR v.1.2.x. Weekly verifications have all checked out just fine so far, but do you advise starting anew with those as well?
James Bucanek


Joined: Feb 14, 2007
Messages: 1567
Offline
My advice would be to wait until I fix this bug

I'm pretty confident that there's no data loss, just migration pains.

- QRecall Development -
[Email]
Ming-Li Wang


Joined: Jan 12, 2015
Messages: 78
Offline
Strange! I sealed the old sys.quanta and created a new one, which had its first capture last night (at 3am this morning), and then immediately failed the verification less than 2 hours later. It's repairing; a diag report will be sent when done.

edit: the repair job checked the partition hosting the archive: no problem. I also verified my system partition with Disk Utility: no problem either.
 
Forum Index » Beta Version
Go to:   
Mobile view
Powered by JForum 2.8.2 © 2022 JForum Team • Maintained by Andowson Chang and Ulf Dittmer