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

Ralph,

The browser code is most likely throwing program exceptions. This can cause all kinds of strange and incomplete behavior in the browser window.

First, please open your Console utility and examine the system.log. Search/look for any messages from QRecall. If you find some, please copy them and e-mail to me or post them.

Secondly, send a diagnostic report in case there was anything captured by the log.

Finally, open up the archive package (control+click/right-click on the archive icon and choose Show Package Contents). If you find a view.plist file inside, throw it away and try to open the archive again.

Every volume (owner, folder, and file) in an archive is logically independent. Deleting a volume (owner, folder, or file) won't delete any other item in the archive, no matter how similar, and no matter how much data they may have in common.

Feel free to delete obsolete volumes that are no longer being captured. It won't affect any items captured for the volume that exists now.

Starting with QRecall 1.2.0(46) you now have a second option, one created specifically to address this situation. The new Archive > Combine Items... command will take two (or more) volumes in an archive, that are actually the same volume, captured at different times, and will stitch them back together into a single volume with one history in the archive.

See the release notes for 1.2.0(46) for the details.

There's a problem/bug in Lion wherein an attempt to access the /dev directory on the startup volume using the core filesystem APIs results in an I/O error.

It doesn't happen on all systems, and it doesn't happen all the time. For months I was unable to reproduce this problem, and then last week my primary development system started showing the same symptoms. I've filed a bug report with Apple a few days ago. It's such a bizarre and blatant error that I'd be surprised if they're not already aware of the problem, but I don't know what's being done about it.

I'm 80% sure that this is an innocuous problem, but I need to do more testing to be sure. Normally, there's nothing in the /dev directory for QRecall to capture, since it's populated almost exclusively with logical device files. So not capturing it shouldn't make any difference.

QRecall 1.2.0(57) will not detect whether the home folder of an account (more specifically if its ~/Library/Application Support folder) is on the same filesystem as the startup volume. If not, it installs its helper binaries in /Library/Application Support (which had better be on the startup volume!).


Adrian,

To test this out, you'll want to upgrade to 1.2.0(57), uninstall QRecall (Command+Option+Shift-Q), remove your symbolic link "hack," and then launch QRecall and let it reinstall itself.

Charles Watts-Jones wrote:QRecallC (my archive): Green Blank Red
Captured today: Green Blank Blank
Verified never: Blank Blank Red
Disk use bar(?): Green with size data below

This means that the archive has recently been captured, hasn't been verified, and you've got a reasonable amount of free space.

Being of the generation that has difficulty with pictograms, I don't understand why the first line shows green and red,

The summary line is the accumulation of the three status values. It's Green (OK) and Red (critical) because there is at least one status indicator that's OK and at least one that's critical. The idea is that you can collapse the details for a compact display of all three.

nor do I understand why the verified line shows red when the log confirms my bi-weekly verify status as OK.

You'll need to perform a verify with 1.2.0(57). The new status system doesn't use the log, and thus doesn't know about any activity prior to upgrading to 1.2.0(57). As soon as your archive verifies again, the status will turn green.

And I really don't want to start my day with a RED icon when the log confirms all is OK. Could RED be reserved for serious trouble please?

It is. In this case, it's saying that your archive has never been verified, which I consider to be pretty serious. It also lights up if there was a error with any action, or if your archive has almost completely run out of free space.

In this particular case, it's an artifact of the upgrade. If the menu bar indicator bothers you, go to QRecall > Preferences > Monitor and uncheck the Show status warnings in icon option. Now the presence of caution or critical status indicators won't show up in the menubar.

Bruce Giles wrote:I don't know how the 504 UID got added to the plist file

The UID was added to the kicker list as soon as you launched QRecall. It checked its configuration, saw that it was not on the list of UIDs to have its scheduler run as a system daemon, and added itself to the list.

... but assuming QRecall did it, then it seems like it also needs to look at any other UIDs in the file and delete any that are no longer valid.

Excellent suggestion.

Done.

When adding a new UID to the kicker list, all existing UIDs will be qualified. Any that don't appear to belong to valid user accounts are now deleted.

Similarly, the kicker process itself will check the UID before trying to launch the scheduler daemon for that user and exit cleanly if the user doesn't appear to exist. This should keep launchd from repeatedly relaunching the kicker for invalid users.