Adrian Chapman wrote:This particular incident serves to remind all of us that while QRecall 2 is a rock solid application most of the time, it is still in beta and we shouldn't grumble if just once in a while it throws a bit of a wobbly.

Thanks, Adrian, for the high praise.

QRecall wouldn't be half the application it is today without the patience and insight provided by its beta testers. I have over 300 diagnostic reports that have been filed during the 1.2 beta program, along with countless e-mail messages and forum posts, which says a lot about the dedication of the QRecall beta users.

This particular incident was a tad unsettling, because I'm winding down development of 1.2, and one hopes not to see any major issues at this stage. QRecall 1.2 is currently feature complete. I'm focusing only on bugs and compatibly issues, moving towards a release candidate later this month.

So a shout out to all my beta peeps: Please run it hard and report anything you find.

Thanks!

Gary K. Griffey wrote:Would be the ability to "toggle" the use of FSEvents on or off as part of a specific defined Capture Action...

Yes it would, and I'll put that on the to-do list.

I have plans for other per-action options, which requires some new plumbing and changes to the action document interface. But once those pieces are in place, adding that particular option would be easy.

Gary K. Griffey wrote:I will use this setting until I find out what corrupted the FSEvents on that volume.

Just to be clear, the FSEvents on the volume are just fine. QRecall doesn't write or change these events. It either ignores them or asks them to be replayed from a certain point in the past.

The bug was not the gathering, interpretation, or ignoring of the system's FSEvents. The bug occurred when QRecall was ignoring all FSEvents (i.e. didn't even ask for them). It was supposed to switch to a mode where it scanned every folder, but instead ended up in a mode where it ignored every folder.

Now that you've run your capture once with QRAuditFileSystemHistoryDays=0.0, everything will now be up-to-date going forward. The only legacy will be earlier layers that did not capture items they should have, which you can eliminate by merging the layers from the past few days with the one you just captured.

If you're not following the other thread, we've found a bug in 1.2.0(56) where QRecall will fail to scan any folders once the QRAuditFileSystemHistoryDays time has expired.

This is fixed in 1.2.0(59), which had already been released. Please update and try your captures again.

Johannes,

QRecall is still confused. I'm not sure exactly what's going on, but it thinks it is installed when it isn't.

Let's do a manual uninstall and try again:

- Hold down Command+Option and choose File >> Quit and Uninstall.
- Trash the ~/Library/Application Support/QRecall folder
- Trash any QRecall* items in ~/Library/Services
- Trash any com.qrecall.* items in ~/Library/LaunchAgents
- Trash the /Library/Application Support/QRecall folder
- Trash any com.qrecall.* items in /Library/LaunchAgents and /Library/LaunchDaemons
- Restart.

Launch QRecall. It should ask for authorization to reinstall itself. Afterwards, please send another diagnostic report.

Gary K. Griffey wrote:I have now re-run the capture several times...and it still does not see any changes in the entire Users folder...

It's a bug.

It turns out that the new "ignore items" feature added in 1.2.0(56) and the QRAuditFileSystemHistoryDays were getting their wires crossed. It's a complicated relationship, but the upshot was that when the QRAuditFileSystemHistoryDays period finally expired, instead of scanning every folder for changes, it scanned nothing. Of course, setting QRAuditFileSystemHistoryDays to 0.0 just makes it happen all the time...

The fix was one line of code. The updated version, 1.2.0(59), should be built and ready within the hour.

Thanks for sticking with this. This is why I value my beta testers so much!

James

QRecall uses an alias—a standard Mac OS structure for keeping a reference to a file or folder—to identify the archive associated with an action.

Aliases can be tricked into pointing to the wrong file, and it drags QRecall along with it. When you mount your Disk B, the OS sees what it thinks is the original archive that belong to the action and QRecall uses that archive.

There's no real harm in this, beyond wasting time. QRecall archives are just documents and are completely self contained. You can copy, move, and rename them as you like.

The duplicate status information is an artifact of the upgrade. The original and cloned copy of the archive were separately updated with status information (since neither had any) and have been assigned different status identifiers. The next time you clone the archive (overwriting the clone with the original), it will also clone the status info and the duplicate status indicator will disappear.

I would prefer QRecall's actions to leave the clone alone.

QRecall treats all archives the same, and has no way to know that an archive is a copy of another archive.

I have on the drawing board some plans to implement rotating and cascading archives, so that QRecall understands the master/slave relationship of this style of backup solution. But for now, it's very egalitarian.

Adrian Chapman wrote:Thanks James. What prompted my question was that in the advanced settings page of the Cookbook & FAQ forum it says "Leopard only" for this parameter and I just wondered if anything had changed with later releases of OS X.

Thank you for noting that. I've fixed the note. This is really a "Leopard and later" feature, because the FSEvents API was added in Leopard.

Out of curiosity I tried changing QRAuditFileSystemHistoryDays to zero so it would perform an exhaustive scan on every capture but I didn't notice any change in the capture speed which seems a bit odd if QRecall has to examine every file.

When QRecall examines a folder to capture, it compares the file metadata (name, size, last modified date, extended attributes, etc., etc.) with what's in the archive. If nothing is different, it assumes that nothing in the file has changed. This is actually very fast for a single folder. Things bog down when QRecall has to reexamine thousands and thousands of folders, most of which contain no changes. So the amount of speed increase that you get from using filesystem events is proportional to the depth and complexity of the folder structure, not the size or content of the files in question.

Also how confident are you that a seven day interval is reasonable?

It seemed reasonable to me. There is no time period by which filesystem events are, or are not, accurate. It's a very robust service and I have never seen it report false information, or had the information it reports become corrupted over time. The problem is that it contains a very small number of fundamental flaws, for which there is no workaround. These flaws can cause it to fail to report changes in a folder that contains changes.

The question of "reasonable" is really one of tolerance. How long are you willing to wait before you are sure QRecall has captured all of the changes on a volume, vs. how much extra overhead are you willing to put up with while QRecall exhaustively rescans the entire volume?

Can you tell me where in the archive the date is stored as I have had a look at the various files and I can't see anything obvious.

I could, but then I'd have to shoot you.

History markers are part of the bookmark structure in a session package. A session package essentially identifies a layer in the archive. The "date" is actually a filesystem history event ID—a 64-bit number that unambiguously identifies a point in the historical event stream. If you're running the beta, you can use the Dump command to dump the session packages in the repository data file. Otherwise, these data structures are opaque.

Johannes,

First, please send a diagnostic report. I'd like to look at the whole log.

The "problem" is that your helper isn't pre-authorized to run using administrative privileges. This was obviously intentional, since prior to 1.2.0(58) it wasn't possible to have a pre-authorized helper installed in a home folder that was on another volume. This is causing two issues.

The first is that 1.2.0(58) is now trying create a new subfolder in /Library so it can store its pre-authorized helper on your startup volume—but it can't, because it's not pre-authorized.

The second, far more serious, problem is that your scheduler is the wrong version. My guess is that you pre-authorized QRecall to use administrative privileges at some point in the past, and then selected the option to run actions when you are logged out. This prompts QRecall to install your scheduler as a system daemon, which requires administrative privileges in install—and uninstall. Now that your helper is no longer pre-authorized, QRecall can't replace the daemon scheduler when you upgraded because it doesn't have the authority to uninstall the existing one. (Note that in this situation QRecall should have informed you that it needed to install the scheduler; you either clicked No in this dialog, canceled the authorization, or the re-install failed; which is another reason I'd like to look at your log.)

To fix this:

- Pre-authorized QRecall to use administrative privileges.
- Hold down the Shift+Option keys and choose File > Quit and Uninstall.
- Discard the /Library/Application Support/QRecall folder you created.
- Launch QRecall.
- Reauthorize QRecall.

At this point, you'll be running QRecall with full authorization, which you can now that you're running 1.2.0(58). If you decide to go back to running QRecall without pre-authorization, uncheck the option to run actions when logged out and then cancel QRecall's pre-authorization.

Steve Mayer wrote:I am using gfxCardStatus to manage the switching of the graphics adapters based off of rules. There may be something there that is screwing with this context setting.

That might be the problem. gfxCardStatus might be forcing the system to switch to the integrated GPU where it wouldn't otherwise. Enabling the application to support GPU switching might simply be letting in the notifications necessary to handle the GPU switch that has already occurred. Apple's Core Animation framework undoubtedly handles the switch correctly.

If that's all true, then the interesting test would be the 3D "Time View" in QRecall (which creates a single OpenGL view). Open an archive, select the Time view, switch GPUs, and see what happens. If the Time view stops working after the switch, I may have to add some code to handle that.

Steve,

Thanks for the great info. I'll add the NSSupportsAutomaticGraphicsSwitching key to the QRecall info.plist.

QRecall uses OpenGL and Core Animation, which in turn also uses OpenGL. It doesn't do anything particularly fancy, so I would expect it to run just fine using the integrated CPU.

It's odd that this doesn't work already. According to Apple's documentation, an application that lacks this switch should cause a new OpenGL context to be created in the higher-end discrete GPU and won't stop using it until the application quits. Apparently, that's not the case.

Ralph Strauch wrote:If you'd still like a report or the system log entries for diagnostic purposes let me know and I'll send them along.

Please do. I'm mostly interested in any messages from QRecall that you find in the Console system.log around the time when the display was acting up. (Your previous diagnostic reports didn't include anything out of the ordinary, so there's no point in sending another.)

Thanks again for all of the feedback.

Adrian Chapman wrote:Does QRecall still perform a periodic exhaustive file system scan in Lion and if so how frequently?

QRecall has a "trusted" duration for filesystem change events. When using FSEvents to determine past changes, it trusts them to be accurate for a period of time. After that, it ignores FSEvents and performs an exhaustive traversal of the filesystem directories. It records the date of this exhaustive traversal in the archive, and begins trusting FSEvents again until the "trusted" duration expires once more.

The default duration is 6.9 days, which should force QRecall to perform a deep scan of the volume once a week.

You can change this duration by setting the QRAuditFileSystemHistoryDays setting to a different value:

# perform a deep scan every 3 days

defaults write com.qrecall.client QRAuditFileSystemHistoryDays -float 2.9

Gary K. Griffey wrote:I ran the capture again early this morning...and the 2 updated documents were not captured.

Clearly, that's not supposed to happen.

I recall from our previous conversations that captures targeting folders and not entire volumes...do not use FSEvents, but, perform a directory "crawl" to locate items that have changed.

If I gave that impression, I apologize. QRecall always uses file system history—when it can—to determine which folders might contain changes.

There's a subtle hole in Apple's implementation of FSEvents, which make it possible to miss changes, but editing a Word or PDF document shouldn't fall through that particular hole.

So either OS X is reporting changes in your Documents folder and QRecall is missing it for some reason, or the OS is failing to report that your Documents folder contains changes since the last capture. It's (almost) impossible to tell after the fact, because QRecall doesn't normally log detailed information about which folders were reported to have changed.

If you want to investigate this, there are a couple of QRecall advanced settings that can help. You can set these with the following Terminal commands:

defaults write com.qrecall.client QRLogFSEvents -boolean true

defaults write com.qrecall.client QRLogCaptureDecisions -boolean true

When both of these options are set, QRecall will log the entire list of folders reported by FSEvents to have changed since the last capture. These two settings can produce a tremendous amount of log file activity, so I won't recommend leaving them on for long periods of time. But they can be useful in determining why a particular item is, or is not, being captured.

defaults delete com.qrecall.client QRLogFSEvents

defaults delete com.qrecall.client QRLogCaptureDecisions

One additional detail...I did create a disk image of the entire volume between the capture yesterday at 1:09 and the capture this morning...could this have caused the capture this morning to miss the 2 file changes?

I can't see how that would have made any difference, but I can't definitively say "no" either.

Ralph Strauch wrote:Neither archive contains a view.plist

Duh, of course they don't. That file is was added in beta 58.

but both contain status.plist and settings.plist. Should I delete either of those.?

No.

Speaking of beta 58, try it when it's released (later today) and see what improvements you see. If you're still having problems, please repeat the same steps as before (search Console, send report, toss the view.plist file).