QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
[b16] folder is unreachable?  XML
Forum Index » Beta Version
Author Message
Ming-Li Wang



Joined: 12-Jan-15 18:20
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
 Filesize 136 Kbytes
 Downloaded:  972 time(s)

This message was edited 2 times. Last update was at 09-Oct-15 20:01

Ming-Li Wang



Joined: 12-Jan-15 18:20
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: 14-Feb-07 10:05
Messages: 1548
Online

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: 12-Jan-15 18:20
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: 12-Jan-15 18:20
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
 Filesize 23 Kbytes
 Downloaded:  1074 time(s)

James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Online

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: 12-Jan-15 18:20
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: 14-Feb-07 10:05
Messages: 1548
Online

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: 12-Jan-15 18:20
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.

This message was edited 1 time. Last update was at 11-Oct-15 18:52

 
Forum Index » Beta Version
Go to:   
Powered by JForum 2.1.8 © JForum Team