David Ramsey wrote:I assume that since I am trying to restore from a new installation, my user ID is different. Wouldn't think I'd need write permission to open an archive, but there you go. I'm reluctant to start mucking with the permissions on the file, especially since I see it has extended permissions. What's my next step?

I don't know if your UID is different or not, but you'll need read and write access to that entire archive package to effectively use QRecall. When you open a legacy (1.2) archive for the first time, QRecall 2.0 will need to make some changes. I suspect this is what's causing the permissions error. Send a diagnostic report if you want me to look into it.

Short answer: if you want to use this archive, you will need to make sure the user with QRecall installed owns it. Usually I recommend placing QRecall archives on a volume that has ownership and permissions turned off, especially if you plan to use the same archive with multiple users. It just simplifies the whole permissions thing.

Bruce Giles wrote:

James Bucanek wrote:If you haven't done so, please send a diagnostic report. I'm still looking for combinations of actions the leave the .lock file locked.

Just now sent a report.

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.

Ralph,

That's a great idea. I'll draft something soon.

David,

My bad. I failed technical support 101 and forgot to ask you what version of QRecall you were running.

QRecall 1.2 is not compatible with El Capitan. It sort of runs, but changes in the OS X 10.11 filesystem and security policies mean that it is incapable of correctly restoring system files and some applications.

If you're still running QRecall 1.2, you need to jump on the QRecall 2.0 beta. Most of the major new features, along with notes on upgrading from 1.2 to 2.0, are described in the release notes for QRecall 2.0.0b6.

The beta is quite stable at this point, and rapidly approaching a final release. I only have 23 items left on my "must fix before release" list.

Paul,

All great suggestions. I'm writing them down, although technical issues might limit a few of them.

The lack of good full-screen support in QRecall is my fault. The only time I "use" full-screen mode is when I accidentally set it off, and then I spend the next minute cursing the name of whoever came up with such a useless and frustrating interface mode while I stumble around trying to remember how to get out of it.

But then I hear from users who love it, so clearly my opinion is not the overwhelming majority of users.

I'll try to get QRecall 2.1 to play nicer in full-screen mode.

Kenneth,

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 Great UI redesign planned for QRecall 2.1.

Bruce Giles wrote:OK, so if I want to get rid of those damaged ("Unknown Unknown Repaired") layers I need to keep merging them with subsequent layers until I eventually hit a layer that recaptures everything that was still missing, and at that point, the damaged layer disappears.

That is correct.

You REALLY don't want to see what the System Log file in the Console app does to me.

I feel your pain ... especially when I look at my server.

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.

That's static text (it doesn't change, except for the name of the archive). I've changed it to "Check volume containing ...".

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".

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.

David Ramsey wrote:If I invoke QRecall by opening the archive file directly, QRecall comes up and immediately crashes.

Try sending a diagnostic report, which will include your crash logs. If you can't send a report, just email a copy of your QRecall* crash log files in ~/Library/Logs/DiagnosticReports/ and your log files in ~/Library/Logs/QRecall/ to support@qrecall.com.

(If they are large, you may want to compress them.)

Bruce Giles wrote: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.

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.

Bruce Giles wrote:For the next ten minutes or so, nothing happened, except that the window said something about waiting for permission to open the archive.

QRecall 2.0 uses a new method for arbitrating concurrent access to an archive. Inside the archive package are some invisible semaphore files (.lock, .share and .semiphore). 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 .lock 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 .lock file locked.

Thank you, everyone, for patiently reporting this problem.

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 too 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!

James Bucanek wrote:

Ming-Li Wang wrote: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.

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".

(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...

Ming-Li Wang wrote: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.

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".

They only started since beta 16, or 15 at the earliest.

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.

Please be aware that there's still a bug in the current QRecall 2.0 beta that may cause the verify command to report that the archive's catalog tree is invalid or that there are "unreachable" directories.

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.

Apple released OS X Server 5.0.4 a few days ago, and the upgrade inadvertently broke the *.qrecall.com website.

Apple's new server includes an integrated proxy service that intercepts and pre-processes all of the requests handled by the Apache web server. Unfortunately, in the process each request gets modified. A lot of pages, particularly the secure pages used to log in and access your account (and buy stuff!), depend on information in this request. This change completely flummoxed the logic the ensures you only access account information via HTTPS, which made it impossible to log in.

Anyway, it should be working again now. If you discover any issues logging in or accessing your account, please drop a note to support@qrecall.com.