Adam Horne wrote:I was thinking how nice it would have been to be able to right-click on the folder in finder and be able to "quick capture" the folder into my QRecall archive.

Adam,

That's an awesome idea! So awesome, it's been in QRecall for years.

Here's the good news: In Mac OS X 10.5 (or in 10.6 if you're running Finder in 32-bit mode) you can get to it by right clicking on an item in the Finder. You'll find a Recapture command that will recapture just the selected items to the archive of your choice. There's also a Reveal command that will open an archive and show you the corresponding item to the one on the desktop.

In Mac OS 10.6 and later, there's a new QRecall Service that provides the same features (starting with OS X 10.6 Apple began dropping support for add-on menu items). You may need to enable these in your System Preferences > Keyboard > Keyboard Shortcuts > Services. Turn on the "Capture to QRecall Archive" and "Reveal in QRecall Archive" services. These commands will then be available in your Services submenu (found in the Finder menu and in other applications), and can also by reached by right-clicking on an item in the Finder.

But here's a little bad news: If you're using Lion, the "Reveal in QRecall Archive" services is broken. (Recapture should still work?let me know if it doesn't.) That's because Lion broke some inter-application communications. The good news is that I've worked with Apple engineers to fix this, and that fix will show up in the next beta release.

Damian Huxtable wrote:How about a preference that if a verify fails, you get some sort of notification outside the log?

If you have Growl, you'll get a notification now.

I'm currently adding a new feature which might satisfy you. After the next beta is released, let me know if you like it.

Gary,

Thanks so much for the thorough follow up.

I can confirm that the one thing QRecall really does not appreciate is having the volume that it's writing to spontaneously dismounted. Typically, this results in a "volume unmount" event being recorded in the log, which I can point to say "ah ha!" But I have to admit, having the mountpoint spontaneously replaced with a different volume is a new one on me.

I'm glad you found the root of the problem.

Victor Magdic wrote:I have followed your suggestion with disk utility and it does not report any problems. I'll continue to keep an eye on it.

I now have a couple of other users reporting similar errors on /dev, so I think it's quirk in Lion. I'm looking into it.

Out of curiosity, does QRecall even backup anything from /dev? as I was under the impression it more of a "virtual directory" and those are not even "real" files, but special device files.

QRecall excludes the contents of the /dev directory, but it does capture (and restore) the directory itself. If an empty /dev directory—with the correct ownership and permissions—does not exist, OS X won't boot. So to perform a full restore of a volume, QRecall must capture and restore the /dev directory. (I haven't tested to see if this is still true in Lion.)

Gary K. Griffey wrote:One question though...if a data read or write error occurred on the original Capture...the Capture would have failed, correct?

Not necessarily. When QRecall writes data, and the OS says the operation was successful, it takes the OS at its word. Data, however, could have been corrupted on it way to the drive (which the OS can't/won't detect), or the data could later get corrupted on the volume. Neither of these problems will be detected by QRecall until it reads that data back again—thus, the suggestion for the verify.

A feature, suggested by another user, that's currently on the to-do list for a future version of QRecall is to immediately re-read all of the data written during a capture to ensure that it wasn't corrupted.

Gary K. Griffey wrote:The archive was stored on the second internal drive...not that it could not be simply a new drive that is bad...but I think the chances are low.

There are two times that electronics fail: when you open the box, and five years from now.

I just seem to remember that there was a bug with the Compact action a while back...but I have not seen it recently.

That bug is still on my to-fix list, but this wasn't it.

Victor,

This is a minor error (from QRecall's perspective) because it involves obtaining the display metadata about a folder (/dev). It's minor because the display metadata (its icon, localized name, wether its extension is displayed, and so on) is purely cosmetic. It is only used by QRecall to properly display the item in the QRecall browser; it doesn't impact the actual data or important metadata (permissions, ownership, access control lists, extended attributes, and so on) that make up the item.

While QRecall isn't concerned, I would be. The error you're getting is an I/O error (-36) which for one of the most basic directories on the volume is absurd (in my no-so-humble opinion). I'd start by using Disk Utility, or your favorite volume repair app, to repair the volume. You'll either have to boot from another partition or run fsck from the command line by starting up in single-user mode. (Holding down the Shift key during boot used to cause fsck to run, but I don't know if that's still true.)

Gary,

I just replied to your diagnostic report before I saw this post. I'll summarize here for the benefit of others (I feel a FAQ coming on...).

Your compact failed when it encountered a damaged data record. There were actually two damaged data records. The repair action encountered the same damaged data; it erased these damaged records, along with the one file that used those records, and repaired the balance of the archive.

As always, I recommend repairing the volume containing the archive using Disk Utility (or your favorite volume repair program). Volume structure corruption can manifest itself as hardware problems.

The key point of interest is that the repair found the same damaged data reported by the compact. That indicates a permanent, rather than a transient, data error. If the location of the damaged data changed, or disappeared, the culprit would have been the hardware (controller, bus, RAM) between the data data on the drive and the CPU.

But since the bad data didn't move it either indicates a media failure (good data that went bad on the drive's surface), or a transient data error when the data was written (bad data preserved on a good surface).

One simply way to diagnose these problems it to regularly verify the archive. If a verify fails, verify it again. If the error is consistent you have a permanent error possibly indicating failing media. If, however, the error moves (or disappears) you have a transient error. This could be a problem with the bus, controllers, or even RAM. Try switching ports, changing cables, changing drive enclosures, or testing your RAM.

Bruce,

Nice catch.

I've fixed this by simply not auto-closing the activity window if there's an update notification displayed.

Gary,

I've spent some time investigating, and I have yet to reproduce the problem here.

From your log files, it looks like your activity monitor process gets launched when you log it (which it should), but for some unexplainable reason none of the other processes can communicate with it. So when you start actions, they don't appear in the activity monitor window.

In the example you posted, you later launched the QRecall application. One of the first things the application does is try to establish a connection with the activity monitor process. When that failed, it restarted and reinstalled the monitor (on the assumption that it wasn't properly installed), at which point the monitor process started to receive notifications and generally behaved itself.

Let's try uninstalling and reinstalling QRecall to see if that makes any difference. Launch QRecall. Holding down the Option+Shift keys, choose the QRecall > Quit and Uninstall command. Wait a few seconds and launch QRecall again. After re-authorizing it, see if the problem comes back.

I love my beta testers. I get the best bug reports, ever.

First, please send a diagnostic report. This will tell me a lot more about which processes were running and what action notifications were sent, what settings you're using, and so on.

Good to know, and thanks for the follow up.

Gary,

I can see that it's not working, but I can't see why. (I'm not seeing the problem here, and my system is configured the same as yours.)

There's obviously something a little strange going on. During the QRecall upgrade, both the scheduler and monitor processes were replaced. But for some reason, the monitor stopped and didn't restart again until later. When it did finally start, the notifications it's supposed to receive when an action starts are never delivered.

Try restarting your entire system again (don't just log out and back in) and see if that makes any difference. Also look in the Console application and see if there are any messages from, or about, QRecall logged around 10:07.

Gary K. Griffey wrote:I guess you ran into more issues?

Several, but most have been dealt with.

QRecall 1.2.0(54) beta is now available.

James Bucanek wrote:This weekend, I swear!

I'm sure it's still the weekend ... somewhere.

Gary K. Griffey wrote:Any timeframe on the new beta release that you mentioned in this thread?

Ah, the plans of mice and men.

I originally planned to have the next beta release out over a week ago, but I ran into complications reworking a critical section of the code that captures a file's metadata, that I would really like to release. To slow things down even more, I was attending Audodesk University this week and just today got back to development.

So to answer your question: This weekend, I swear!