Gary K. Griffey wrote:Is there any update on this issue?

This, and related issues, were addressed in QRecall 1.2.0(53), QRecall 1.2.0(58), and again in QRecall 1.2.0(59).

The changes in 1.2.0(53) should have solved, or at least improved, the monitor window problem that you're describing. I can't fix the communications failures in Lion, but the helper process is now much more aggressive about trying to re-establish a connection with the monitor window. When I start an action manually, ever once in awhile, it does not immediately appear in the activity window. But the action now knows this and retries about every 15 seconds, so after 15-30 seconds it finally appears. My advice is to leave the monitor process alone for a minute or so and see if it catches on.

The status of the actions in the QRecall actions window is not as robust. Basically, if the scheduler's announcement to the application gets lost, the application simply won't update its display until the next announcement arrives. But you could quit and restart QRecall to see if that causes it to catch up.

And please send a diagnostic report. Maybe there's some clue about what's (not) happening in the log.

Adrian Chapman wrote:Do the problems you have encountered relate to using a Zevo formatted disk for archive storage and/or for capturing files on a Zevo formatted disk?

The only thing I've testing is capturing to a QRecall archive stored on a ZFS volume. I'll try capturing and restoring files on a ZFS volume when I have a chance.

jeffry luvall wrote:I don't think switching over to ZFS will be as easy as claimed.

It may not be ready for prime time just yet, but I have very high hopes for ZFS. I think it's a fantastic storage technology and I look forward to working with Ten's Complement on getting these issues ironed out.

jeffrey luvall wrote:Can Qrecall be used with ZFS Storage Technology formatted drives?

Not at this time, unfortunately.

A few customers, and myself, have tried using QRecall on a ZFS volume using the ZEVO implementation from Ten's Compliment. QRecall uses a large number of the Core File API functions in OS X, and there seems to be some idiosyncrasies with a handful of these functions when executed on a ZEVO formatted volume—enough idiosyncrasies that QRecall won't work.

I've documented the issues that I've found and I'm working with Ten's Compliment in the hopes of resolving them and getting QRecall fully ZFS compatible.

Adrian Chapman wrote:

James Bucanek wrote:Question: Is your QRecall application on a different volume than your home folder?

Yes

Good, because that's the bug I addressed.

Gary K. Griffey wrote:This file name, however, is in reality, the last file that was captured successfully...not the file that is currently being captured.

Sometimes.

Normally, the name being displayed is the file that is currently being captured or the folder that was just captured.

The display of items names and icons, however, is complicated by a number of factors. QRecall doesn't (usually) display the name of invisible items, items inside invisible folders, items that are normally inaccessible as a regular user, or items inside packages. So it is often displaying the name of the file or folder it just finished capturing, rather than the (invisible/hidden/inaccessible/package) item it's actually capturing.

Is this working as designed?

It's working the way it was written.

I've had an item on the to-do list to display something more intelligent under these circumstances for a very long time. But given the complexity of the problem, and the benefits, it has a rather low priority.

I recently addressed this issue, but the fix hasn't appeared in a beta release yet.

Question: Is your QRecall application on a different volume than your home folder?

This message appears when the activity monitor process fails to find the QRecall application bundle. The QRecall bundle contains the Sparkle upgrade framework, which the activity monitor uses to determine if a QRecall upgrade is available. If the activity monitor can't locate and load the framework, the worst thing that will happen is that an upgrade notification won't appear in the activity monitor window.

Third time's the charm. Please download and try QRecall 1.2.0(61) alpha.

Install note: Unless you've previously uninstalled QRecall completely, use the Install QRecall application to perform the upgrade.

Johannes wrote:But it installed the helpers in the user's Library folder only.

That's actually correct, since your copy of QRecall isn't pre-authorized.

I was not asked to authorize

also correct

nor could I do it manually from the preferences pane.

That's not right.

When I try the installer, it tries (and fails) to create the folder /Library/Application Support/QRecall.

The installer doesn't create that folder, so I'm not sure what's going on there.

I've sent a diagnostic report.

I'll take a look at it.

Ralph Strauch wrote:Where does qrecall store actions, and is there an easy way for me to retrieve the necessary files from my backups and reinstall them?

QRecall stores its actions in ~/Library/Preferences/QRecall/Actions.

Each action is stored in a separate document.

You may need to restart the QRecall application before it sees changes in this folder, and you may need to restart the scheduler before it sees any changes.

Alternatively, making a superfluous change (i.e. go to the QRecall actions window, duplicate an action, and then delete the duplicate) should signal all processes to re-read the contents of that folder.

Ralph Strauch wrote:I also discovered something I hadn't known before -- that qrecall can back up to two different archives at the same time.

The only thing you can't do is run two actions on the same archive at once.

The scheduler tries to do some basic load balancing and resource ordering, which you can adjust in QRecall's scheduler preferences ("Maximum concurrent actions" and "Maximum actions per volume"). If you set these to Automatic, QRecall will examine how much RAM and CPU cores you have, and pick an optimal number of actions to run concurrently.

I'm still getting an error on the dev folder when I backup my full drive. I'd like to just exclude that from the backup, but don't see any way to exclude invisible folders. Is there an easy way to do that?

Not really, and it won't help. The errors you're getting from /dev wouldn't even go away if you excluded it from the capture (you'd get a different error trying to exclude it).

I've filed a bug report with Apple.

Christian,

I received your diagnostic report, and I'd like you to try something.

Attempt to repair your archive again, but this time make sure you unselect the "Use auto-repair information" option before starting.

Afterwards, please send another diagnostic report so I can compare the results.

Thanks.

Download and install QRecall 1.2.0(60) alpha and let me know if that fixes things for you.

Thank you for your patience.

Ralph,

Update to 1.2.0(59), and take a look at the thread "Incremental Capture Issues...".

Gary K. Griffey wrote:obviously, when QRecall is capturing a mounted SMB share...it could not use the FSEvents method since the data is actually housed on a remote device...does QRecall just crawl through the directories on the SMB share and look for changes?

Correct.

I also noticed that the SMB capture never has the "Locating Changes Since XXX" message in the log...does this message only apply to FSEvents enabled captures?

Also correct.

The message "Locating changes since..." indicates that QRecall is using FSEvents to determine what folders contain changes. There are lots of reasons it won't/can't do this: The OS doesn't support FSEvents, the volume format doesn't support FSEvents, the FSEvent information on the volume is incomplete or incompatible, and so on.

If any of these reasons prevent it from using FSEvents, it falls back to performing an exhaustive search of the directory structure.

Christian,

The fact that your package.index file is 0 length is just one indicator that you were unable to repair the archive. And although the other .index files appear to be reasonable lengths, none of them are usable either.

All of the information about your archive is stored in the repository.data file. The various .index files all contain information found in the repository.data file, organized for efficient retrieval. When you repair or reindex an archive, mostly what QRecall is doing is rebuilding the information in the .index files from the data records in the repository.data file.

Christian Roth wrote:However, trying to repair it failed with a "disk or network error".

This is the real problem. It's almost a tautology to say, but if QRecall can't read the contents of the repository.data file, you can't use the archive, which includes reconstructing the index files.

QRecall has a repair mode for recovering an archive on a device with unrecoverable media failures. Prepare a second drive with enough free space to copy the archive, then select the repair command and skip over the volume repair. Uncheck the "Use auto-repair" option and check "Copy recovered contents to new archive". Under these circumstances, I also recommend the "Recover lost files" option. When you start the repair, QRecall will prompt you for a destination. It will then proceed to copy everything it can from the existing archive to the new archive; anything that can't be read will be omitted.

Note that if the source drive is encountering I/O errors, this process can take an extremely long time to work. Most drives will take a lot longer to read a region of the drive that's failing than it would normally, sometimes a 100 times longer.

Also be aware that there are lots of causes for slow hard drive deaths, one of which is heat. If you have one of those "whisper quiet" external drives, it may be overheating. I was recently able to recover almost all of the data from an archive on an external drive, that wouldn't even mount for a friend of mine, by pulling the drive out of the enclosure and running it with an external fan blowing on it.