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.

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