The strange case of the QRecall 2.0 beta Verify action

How about a single short sentence at the top of the list of repair options? Something like this:

"Deselecting a selected repair option may make other repair options available."

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:

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.

I do vaguely recall QRecall crashing once recently, but I have no memory of what I was doing at the time. The standard Apple crash reporter dialog came up and I submitted it. Does Apple share any of that info with developers, or do they just use it to fix problems in their own software? Anyway, I'm glad you figured it out.

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?

Bruce Giles wrote:The standard Apple crash reporter dialog came up and I submitted it. Does Apple share any of that info with developers, or do they just use it to fix problems in their own software?

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.

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?

Rebooting won't have any affect on this problem.

If you have an action that's stuck "waiting to acquire access" and you are absolutely 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 .lock, .shared, and .semaphore files you find:

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

The action trying to gain access to the archive will then proceed immediately.

Thanks, but even though that wouldn't be difficult to do, I could imagine myself managing to screw something up somehow. I think I'd be better off to just wait the 10 minutes. Now that I know what the issue is, I guess I can be a little more patient.