Kenneth,

Yikes, that's a tough one.

You've obviously tried to create a capture action that runs when the Microsoft Database Daemon quits, and since that doesn't work it makes me think that the daemon app either isn't a standard Cocoa application or Microsoft is launching it using their own mechanism (which is not unlikely, Microsoft tends to do things "their way"). Regardless, the Microsoft Database Daemon seems to be flying under the workspace radar.

Unfortunately, this probably means my next suggestion won't work either. That suggestion is to create a set of actions that run when each application quits, and to each one add a one minute delay and a condition that skips the action if the Microsoft Database Daemon is still running. But if the workspace doesn't see the daemon app launch and quit, then it probably can't tell if it's running either.

Going a little deeper, it might be possible to script something that can test (via ps or some other tool) if the database daemon is running and then script the capture to start using the new qrecall tool, but I don't have any good suggestions on what might run that script in a timely fashion.

I have some enhancements on the horizon (probably in 2.1) that would solve this, but those are still on the drawing board...

Cody,

You are not alone. On a few systems, QRecall can't delete the old (1.2) QRecallService.service plugin in your ~/Library/Services folder.

If that's that case, it's an easy fix:

Quit QRecall

Open your ~/Library/Services folder (in the finder hold down the Option key and choose Go > Library)

Trash the QRecallService.service plugin

Launch QRecall again

That should allow QRecall to install the latest plugin, and the Capture Preferences service should then become available.

If you continue to have issues, send a diagnostic report.

Thanks!

2.0 took about 6 months longer than originally planned, but that seems to be the way software goes.

Yes, there are lots of new features and ideas in the works—enough to keep me busy for the next several years.

But the most enjoyable part of working on QRecall has been my customers. They're a smart, well informed, bunch who share a passion (some might say an obsession) with data integrity and security. It's been a pleasure, and I look forward to getting to know more of you.

Adrian Chapman wrote:Please can you clarify the value, or otherwise of using QRecall's redundancy feature if the archive is stored in a RAID 5 array or a ZFS Mirror.

There are no advantages. If you are using a filesystem or device that performs error correction, your archive's data redundancy should be set to "none".

QRecall's data redundancy in inferior to both hardware (RAID5) and filesystem-level (ZFS) error correction. It cannot protect against whole-device failures (like RAID5) and it cannot evenly distribute correction codes across the media (as ZFS can). (QRecall "encourages" the filesystem to distribute the correction blocks, but since applications have no control over how a filesystem organizes blocks, this can't be guaranteed.)

QRecall's error correction is intended for use on simple hard drives that lack any kind of error detection or correction.

QRecall 2.0.0(38) (A.K.A. release candidate 2) just went live.

Capture (or any other scheduled action) should be just fine. The probably is in the display code that shows items loading in the background when you open the archive window.

Ralph,

A last minute change in 2.0.0(37) introduced a race condition that could crash the browser when items are being loaded in the background. This bug has already been identified and fixed, but you'll have to wait until the next release, hopefully tomorrow.

You're not hitting any QRecall limits.

I suspect that you're hitting a (possible bug) in the sparse disk image that's corrupting the volume when you try to write a file that's larger than 1 TB.

I suggest writing the archive to regular volume (not a disk image). If that's not possible, try creating a regular (non-sparse) disk image and see if that makes any difference.

QRecall 2.0 requires OS X 10.8 or later. I'm sorry if that wasn't clear. I'm sure that was mentioned somewhere in the 400 pages of release notes...

Dr. D wrote:I am consistently getting a corrupt archive backing up to a fresh copy of a working archive, just around the 1 TB size.
As I was wondering if there is any limit in QRecall (or possibly in accessing the archive on a networked volume) ...

All filesystems have an upper file size limit. In most modern filesystems, the upper limit is so large as to be essentially unlimited, but older filesystems and file servers can be limit the size of your archives.

First, consider the filesystem (format) of the volume containing your archive. Ideally, it should be Mac OS Extended (also known as HFS+). This is the native filesystem for OS X and will handle archives of any size. If it isn't Mac OS Extended, consider reformatting it, if that's an option.

If the archive is stored on a remote volume then the combination of the server and server volume's filesystem will determine the maximum file size. You'll need to investigate both. For example, some Windows-compatible filesystems are limited to 4GB files, older AFP (Apple File Protocol) servers are limited to 2TB, and some Linux-based servers are limited to 1TB. Some even older filesystems, like FAT32, are limited to 2GB (not TB) files, but you would have hit that limit a long time ago.

From your other post, I suspect you're running QRecall 1.2.x. New code in QRecall 2.0 determines the maximum file size for a volume and uses that to limit the size of the archive. Unfortunately, that code isn't in QRecall 1.2.

If reformatting your volume isn't an option, or the limit is in your fileserver, consider splitting your archive. You might capture your System and Applications folders to one archive and your user folders to a second archive. Excluding items you don't need to capture (like log files) and turning on compression are other ways of reducing your archive's size.

Ralph,

The "problem closing archive" issue is probably unrelated. It appears that you left the archive open, and that computer later went to sleep, and while it was asleep some other process updated that archive, and when the first computer woke back up and tried to close the archive it found it in an unexpected state. Annoying, but by itself it doesn't mean anything bad happened.

The "invalid parameter" error is actually a red herring. The real problem happened a few seconds earlier when QRecall tried to duplicate the negative.index file. The copy failed with a "Timeout" error. This usually means the computer lost it's connection with the server, most like an interruption in WiFi.

That probably left the copy of the negative.index file half done, which explains the invalid negative hash map size error on the next attempt.

I suspect a simple repair (possibly even just a reindex) will fix the problem.

Ralph,

I wouldn't classify this as a "conflict". It's more "a trivial event that's being reported in the log as a problem because of a bug."

Basically all your log is reporting is that that a few files inside the invisible Genie9/Zoolz directory couldn't be captured because the files got deleted between the time that QRecall read the directory and the time it actually started to capture them.

That's actually a bug. There's no logical difference between a file being deleted before the directory is read and after, so this should not be logged as an error. The next version of QRecall will fix this.

Ralph,

What happens when you choose View > Show Toolbar?

Ralph Strauch wrote:I deleted that layer and reran the backup, and I'm back in business.

That's great news. This is also further confirmation that the error correction codes are, under specific circumstances that have yet to be fully identified, interfering with the repair process. (And the irony of error correction causing errors is not lost...)

Is it possible to exclude files within a package

There are several ways:

When adding excluded items to the archive's settings, hold down the Shift key when clicking the "+" button, and the dialog will allow you to choose items inside a package.

Use the Finder's Show Package Contents command, find the item, and drag it into the exclude list or use the Capture Preferences service to set the "Do Not Capture" preference. (Don't do this inside signed applications—it will alter the digital signature of the package and OS X will think it's been hacked).

Use the qrecall captureprefs command to set the "Do Not Capture" preference for one or more items.

and is it possible to exclude files by name regardless of where they occur?

That is a common request, and it on the short list of features to add in the next major version.

I miss being able to select and run an action from the same window. Not a big deal, but just a minor annoyance.

You should be able to do that now. Could you be more specific about what part of the interface you're using, what you're trying to do, and/or what's not working?

Ralph Strauch wrote:I shut down and restarted the iMac, interrupting the ongoing backup. The archive now appears to be unrepairable, ...

Ralph,

What leads you believe the archive is unrepairable?

QRecall has special mechanisms for dealing with exactly this kind of failure, because it's so common. The auto-repair feature should, under normal circumstances, automatically repair an archive that's experienced an interrupted capture or merge, and immediately restore it to its former state. The next action will then proceed as if nothing happened.

If, for some reason, auto-repair didn't fix archive, the repair action should most certainly reconstruct the archive, and preserve most (if not all) of your history. If the repair isn't working, then there's something else that's dreadfully wrong.

Also be aware that there are several issues regarding repair and data redundancy under investigation. If your archive has redundant data, try this:

1) In the Finder, select the archive, right/control+click, and choose "Show Package Contents"
2) Locate the repository.data file.
3) Find all of the repository_*.* companion files. They'll have names like 'repository_p8w8k16m2.0.anvin_reed_sol' and so on.
4) Trash all of the repisitory_*.* companion files, BUT DO NOT trash the 'repository.data' file.

Close the window and try to repair the archive again. Afterwards, send another diagnostic report so I can compare the results.