https://forums.qrecall.com/posts/list/3.page JForum - http://www.jforum.net
This issue is still being investigated, but early exploration would indicate that this is an erroneous error; the archive is not damaged and does not need to be repaired.

For the time being, please ignore this error. That is, you don't need to repair your archive if the only action complaining is the verify, and it is reporting one of these two failures.

But do please send a diagnostic report should it happen to you. In the comments, please indicate if the archive was created with QRecall version 2.0 or if it is an older archive that you converted to 2.0.]]> https://forums.qrecall.com/posts/preList/547/2525.page https://forums.qrecall.com/posts/preList/547/2525.page GMT
After some digging just now I found my user profile folder was the culprit. Now, remember I said I had a dedicated partition for my documents which is mounted at boot at ~/Documents? I unmounted the partition and tried again and sure enough the test archive verified without error.

Note that I've been using the same arrangement for a long time and neither QRecall v1.2.x nor early v2 betas had any trouble with it. They only started since beta 16, or 15 at the earliest.

A diag report has been filed.]]> https://forums.qrecall.com/posts/preList/547/2526.page https://forums.qrecall.com/posts/preList/547/2526.page GMT I can't imagine any reason why your environment would make any difference to the verify. In theory, the verify simply compares the structure defined by the individual directory records with the index of the directory structure. It shouldn't matter what your computer environment is, and should succeed even if ran on a completely different machine.

Having said that, I should also say that I should never say "never". :?

[quote]They only started since beta 16, or 15 at the earliest.[/quote]
This I agree with. I strongly suspect that a subtle change in how volume identifiers and mount points are dealt with is the root cause of this issue. I've been poring over the code change logs looking for a cause, but have yet to identify it.

I have a new beta that I'll probably release today. It includes some code to log more information about these verify errors, in the hopes that I can get more examples to look at. If you encounter this issue with 2.0.0b18, please send a diagnostic report and (if practical) stop using that archive. I may have some diagnostic commands for you to run on it.

The search continues in ernest.
]]> https://forums.qrecall.com/posts/preList/547/2527.page https://forums.qrecall.com/posts/preList/547/2527.page GMT I can't imagine any reason why your environment would make any difference to the verify. In theory, the verify simply compares the structure defined by the individual directory records with the index of the directory structure. It shouldn't matter what your computer environment is, and should succeed even if ran on a completely different machine.

Having said that, I should also say that I should never say "never". :?[/quote]
(It's lucky I added that caveat.)

I do have one more question: did you unmount the volume (mount point) at ~/Documents before you made the capture, or before you performed the verify?

Because I'm now beginning to suspect that the former could make a difference...]]> https://forums.qrecall.com/posts/preList/547/2528.page https://forums.qrecall.com/posts/preList/547/2528.page GMT Sorry for not making it clear earlier. By "trying again after unmounting the ~/Documents partition" I meant the whole thing: creating a new test archive, capturing my user profile directory tree, and then verifying the archive.]]> https://forums.qrecall.com/posts/preList/547/2529.page https://forums.qrecall.com/posts/preList/547/2529.page GMT
I think I finally figured it out. QRecall 2.0.0b18 is out and contains the fix.

I kept thinking that it was a problem with the logic that finds and compares volume identifiers. As it turns out, I was going in the wrong direction. The issue was that the volume identifier was doing [i]too[/i] good of a job, identifying mountpoint directories as volumes when they should have been treated as sub-directories. The details are explained in the release notes.

Happy capturing!
]]> https://forums.qrecall.com/posts/preList/547/2530.page https://forums.qrecall.com/posts/preList/547/2530.page GMT https://forums.qrecall.com/posts/preList/547/2531.page https://forums.qrecall.com/posts/preList/547/2531.page GMT
Action 2015-10-21 22:51:06 ------- Delete items in Macintosh HD.quanta
Action 2015-10-21 22:51:06 archive: /Volumes/Seagate 2GB Backup/QRecall Backups/Macintosh HD.quanta
Action 2015-10-21 22:51:06 Minutia Waiting for permission to open archive
Action 2015-10-21 23:00:06 Minutia Broke stale lock file
Action 2015-10-21 23:00:06 died: 2015-10-22 02:51:06 +0000
Action 2015-10-21 23:00:06 Minutia Acquired permission to open archive
Action 2015-10-21 23:00:08 Delete 6 items
Action 2015-10-21 23:00:08 Deleting dev
Action 2015-10-21 23:00:08 Deleting dev
Action 2015-10-21 23:00:08 Deleting dev
Action 2015-10-21 23:00:08 Deleting dev
Action 2015-10-21 23:00:08 Deleting home
Action 2015-10-21 23:00:08 Deleting net
Action 2015-10-21 23:00:10 ------- Delete finished (00:03)

This is actually at least the second time this has happened. Shortly before, I had attempted to delete an incomplete layer. When nothing happened after a few minutes, I got impatient, canceled the delete, and rebooted the computer. I haven't yet tried again to delete that incomplete layer.

At the moment, I'm running another verify. When that completes, I'll try again to delete the layer and I'll report back here with the details.

-- Bruce]]> https://forums.qrecall.com/posts/preList/547/2532.page https://forums.qrecall.com/posts/preList/547/2532.page GMT
The verify completed and reported no problems of any sort. Also, I was able to delete the last incomplete layer, and it deleted almost immediately. But now there's something odd going on with the Merge command. I have a number of incomplete layers going back several weeks. I attempted to merge them with a subsequent complete layer, but after doing so, I end up with a layer marked as "unknown".

For example, before the merge:

Layer 26: Monday, October 19, 2015 at 1:00 AM 34.4 MB 121 items
Layer 27: Monday, October 19, 2015 at 2:48 AM 36.9 GB Incomplete
Layer 28: Monday, October 19, 2015 at 7:00 AM 102.5 MB 144 items
Layer 29: Monday, October 19, 2015 at 1:00 PM 40.8 MB 138 items
Layer 30: Monday, October 19, 2015 at 7:02 PM 105.3 MB 132 items

Then I selected both Layer 27 and 28, and merged them. After the merge:

Layer 26: Monday, October 19, 2015 at 1:00 AM 34.4 MB 121 items
Layer 27: Unknown Unknown Repaired
Layer 28: Monday, October 19, 2015 at 1:00 PM 40.8 MB 138 items
Layer 29: Monday, October 19, 2015 at 7:02 PM 105.3 MB 132 items

So now I select the new Layer 27 (Unknown) and Layer 28 (1:00 PM) and try to merge these. After the merge:

Layer 26: Monday, October 19, 2015 at 1:00 AM 34.4 MB 121 items
Layer 27: Unknown Unknown Repaired
Layer 29: Monday, October 19, 2015 at 7:02 PM 105.3 MB 132 items

So, it seems that and Unknown layer can't be eliminated by merging, but if you try, it appears to "eat" the subsequent good layer. After trying this a few times, I closed and re-opened the archive, and did another Verify. The verify found no problems, and subsequent scheduled captures are proceeding without error.]]> https://forums.qrecall.com/posts/preList/547/2533.page https://forums.qrecall.com/posts/preList/547/2533.page GMT QRecall 2.0 uses a new method for arbitrating concurrent access to an archive. Inside the archive package are some invisible semaphore files ([b].lock[/b], [b].share[/b] and [b].semiphore[/b]). These allow QRecall to play nice on filesystems that don't support the read-shared/write-exclusive access modes, and on networked volumes, NAS devices, and so on.

An outstanding bug, that I'm still investigating, is that the [b].lock[/b] file doesn't get "unlocked" when it should. This causes QRecall to think that a remote process is using, or updating, the archive. QRecall performs a series of tests, which take about 9-10 minutes, to ensure that no other process is modifying the archive. Once it's convinced that the semaphore files are stale, it resets them, acquires the access it needs, and proceeds to perform the action.

If you haven't done so, please send a diagnostic report. I'm still looking for combinations of actions the leave the [b].lock[/b] file locked.]]> https://forums.qrecall.com/posts/preList/547/2534.page https://forums.qrecall.com/posts/preList/547/2534.page GMT You can "fix" a layer by merging, but only under specific circumstances.

When merging with a damaged or incomplete layer, the later (good, complete) layer must have captured anything marked as damaged or incomplete in the earlier layer for the merged layer to be considered complete again.

For example, on Monday you capture your Documents, Music, and Pictures folders. On Tuesday you recapture your Music and Documents folders.

On Wednesday, a media failure damages your archive requiring it to be repaired. During the repair, the Pictures and Music folder in Monday's layer are marked as damaged because data from one or more files in those folders was lost.

You now have two layers. Monday's layer is marked as "damaged".

If you merge these two layers, the merged layer will still be marked as "damaged" because Tuesday's layer did not recapture the Pictures folder from Monday. It did recapture the Music folder, so that folder is no longer damaged in the layer, but it inherits the damaged Pictures folder, so the layer is still "damaged".

If you recapture the Pictures folder in a new layer, and merge that with the previously merged layer, the new layer will be complete.

(Note that when a capture action sees that the latest layer(s) are damaged or incomplete, it automatically ignores filesystem change history and forces the recapture of all files and folders marked as damage or incomplete. This guarantees that if you then merge the newly captured layer with the previous one(s), the resulting layer will be complete.)

And this actually gives me an idea for a new feature. I think we need a "damage" report or search mode that will show you just those directories or files that have been damaged.]]> https://forums.qrecall.com/posts/preList/547/2536.page https://forums.qrecall.com/posts/preList/547/2536.page GMT
Just now sent a report.

-- Bruce]]> https://forums.qrecall.com/posts/preList/547/2537.page https://forums.qrecall.com/posts/preList/547/2537.page GMT
By the way, two more things. With regard to the verify errors discussed in this topic, when the Verify command reports an error and you choose to repair it, you get the option of verifying or repairing your volume first, which is good. But no matter whether you choose verify volume or repair volume, the top of the sheet says "Repairing volume". That confused me a little, when I was sure I had clicked the Verify button, not the Repair button.

Second, after I got past the volume verify/repair, when the Repair Archive sheet comes up, the only option not grayed-out was "Reindex only". I had already done enough of these that I was pretty confident that "Reindex only" wasn't going to work, but I had to go though that first, and wait for it to fail, before I could go on with the "Use auto-repair information" box checked, and that one actually did fix the archive. Is that the way it's supposed to work?]]> https://forums.qrecall.com/posts/preList/547/2540.page https://forums.qrecall.com/posts/preList/547/2540.page GMT That is correct.

[quote]You REALLY don't want to see what the System Log file in the Console app does to me.[/quote]
I feel your pain ... especially when I look at my server.

[quote]With regard to the verify errors discussed in this topic, when the Verify command reports an error and you choose to repair it, you get the option of verifying or repairing your volume first, which is good. But no matter whether you choose verify volume or repair volume, the top of the sheet says "Repairing volume". That confused me a little, when I was sure I had clicked the Verify button, not the Repair button.[/quote]
That's static text (it doesn't change, except for the name of the archive). I've changed it to "Check volume containing ...".

[quote]Second, after I got past the volume verify/repair, when the Repair Archive sheet comes up, the only option not grayed-out was "Reindex only".[/quote]
When you click on the handy "repair" button in a error message or dialog, QRecall pre-configures the repair options based on what it thinks the problem is. For problems with the index files, it assumes a reindex is all that's necessary. It the error is in the primary data file, the options are pre-configured for a full repair.

In your case, the first problem discovered was in an index file and QRecall assumed a reindex would fix it. It did not. The reindex discovered a problem in the primary data file, so the second time the repair options were pre-configured for a full repair. But you could have changed it to a repair on the first go.

Once in the dialog, you can reconfigure the options to whatever you want. Just be aware that the options are highly interdependent. The "Reindex only" option is incompatible with all of the other options, so as long as "Reindex only" is checked, all of the other options are disabled. Uncheck "Reindex only" and you'll have the opportunity to select a different set of options. The "Use auto-repair information" and "Copy recovered content to new archive" options are also mutually exclusive; selecting one disables the other. And once you've picked any other option, the "Reindex only" option will be disable, because, you know, mutually exclusive.]]> https://forums.qrecall.com/posts/preList/547/2542.page https://forums.qrecall.com/posts/preList/547/2542.page GMT
OK, now I understand, after I played with it a bit. My first impression was that this is a dialog that's crying out for radio buttons instead of checkboxes, but the "Recover lost files" and "Recover incomplete files" options don't fit that mold either. They can be a primary choice, if you don't pick any of the top three, or a secondary choice, if you pick either of the first two. So I have to say I don't really like the way those options are laid out, because it's not inherently clear what you can and can't do. You have to turn off the checked "Reindex only" option before it becomes clear that you can do something else. But honestly, I can't come up with a better way to do it.]]> https://forums.qrecall.com/posts/preList/547/2543.page https://forums.qrecall.com/posts/preList/547/2543.page GMT
"Deselecting a selected repair option may make other repair options available."]]> https://forums.qrecall.com/posts/preList/547/2544.page https://forums.qrecall.com/posts/preList/547/2544.page GMT
That's a great suggestion, but I have a couple of other ideas. Just deciding whether I want to try one today or wait until the [i]Great UI redesign[/i] planned for QRecall 2.1.]]> https://forums.qrecall.com/posts/preList/547/2545.page https://forums.qrecall.com/posts/preList/547/2545.page GMT Just now sent a report.
[/quote]

I figured out what caused your archive to get "locked" up. You had the archive open in a browser window when your QRecall app crashed.

I was able to use the crash log to figure out why it crashed, and fix that problem. But the result is that the archive was still in "shared-read" mode, thinking it was still open in an archive browser.

You didn't notice it immediately because you probably reopened the archive again as soon as you relaunched the QRecall app. This wasn't a problem because any number of processes can share "shared-read" access. (This is why you can browse an archive while simultaneously recalling from it.) The delete action, however, has to first ensure that all processes with shared-read access have closed the archive and relinquished it.

So, this is expected behavior. If you have the archive open for any reason (browsing, verify, recall, capture, ...) and that process crashes, the next process that wants use it has to go through the arbitration procedure to reestablish access to it.]]> https://forums.qrecall.com/posts/preList/547/2553.page https://forums.qrecall.com/posts/preList/547/2553.page GMT
I probably did immediately re-launch QRecall and re-open the archive. If something like this should happen again (and it hasn't, so far), is there anything I can do short of rebooting to force the archive closed?]]> https://forums.qrecall.com/posts/preList/547/2561.page https://forums.qrecall.com/posts/preList/547/2561.page GMT Apple shares some crash data with iOS developers, but not OS X developers. Fortunately, the crash logs are also written to ~/Library/Logs/DiagnosticReports/, and when you submit a diagnostic report in QRecall it uploads a copy of any QRecall related crash logs it finds there.

[quote]I probably did immediately re-launch QRecall and re-open the archive. If something like this should happen again (and it hasn't, so far), is there anything I can do short of rebooting to force the archive closed?[/quote]
Rebooting won't have any affect on this problem.

If you have an action that's stuck "waiting to acquire access" and you are [i]absolutely[/i] sure that the archive is not being accessed by another process, you can (a) wait 10 minutes for the arbitration logic to do its thing or (b) impatiently open the archive package and delete any invisible [b].lock[/b], [b].shared[/b], and [b].semaphore[/b] files you find:

[code]rm /Path/To/Archive.quanta/.[ls]*[/code]

The action trying to gain access to the archive will then proceed immediately.]]> https://forums.qrecall.com/posts/preList/547/2563.page https://forums.qrecall.com/posts/preList/547/2563.page GMT https://forums.qrecall.com/posts/preList/547/2564.page https://forums.qrecall.com/posts/preList/547/2564.page GMT