I don't have a fixed date set for the release of QRecall 1.2. There are a few more major features planned for 1.2 along with a fresh coat of paint (courtesy of Rory Prior, who designs all of the icons).

That, plus lots and lots of testing, and version 1.2 should be ready to roll out by late September or early October.

Ralph,

Sorry to hear you're having problems. I spent some time this morning investigating this problem. I have some information, but no definitive cause for your issue.

Let's start with QRecall and FileVault. The two have a rocky history, and I don't generally recommend QRecall for Filevault users. The original FileVault worked by replacing your home directory with a mount-point to an encrypted disk image. While arguably a very elegant solution, it trips up QRecall (and similar device/volume oriented backup solutions) in many subtle ways.

The new FileVault in Lion is actually much simpler, architecturally. Lion's FileVault encrypts the entire volume at the volume level. When mounted, the entire volume appears as a single, completely ordinary, volume to the operating system. Thus, as long as you're logged in, QRecall should behave normally. Testing this morning on an encrypted Lion volume would seem to confirm that conclusion.

So let's get to your specific problems.

First, it's not surprising that QRecall it taking a long to time recapture your volume. When you turned on FileVault, you essentially reformatted your hard drive; it now appears as "HSF+ (journaled, encrypted)" in Disk Utility. As a never-before-seen volume (from QRecall's perspective) it will be completely recaptured. As you rightly guessed, doing this to an Airport base station isn't the fastest solution, but also the added layer of decryption that has to happen means that everything is going to be little slower.

After you moved your archive to another volume you started getting a "cannot convert FSRef to path" error. Frankly, this just doesn't make much sense. It's an internal inconsistency error that should simply never happen, at least not where it would appear to be happening. By the way, thanks for sending the diagnostic report. That made looking into this much easier.

So I suspect something strange with the archive or the volume it's now on. Here's some thoughts:

- You mentioned that you were going to repair the archive, which I agree might fix something.
- I would suspect the volume, but you already repaired that so let's assume that's not the issue.
- Choose the volume that contains the archive it the Finder, choose Get Info, and check the "Ignore ownership on this volume" option.
- Alternatively, make sure you have the correct read/write permissions for both the archive package folder and all of the files it contains.
- Try opening the archive package (from the Finder, right/control+click on the archive choose "Show Package Contents") and deleting any "negative" index files you find. This is the file that QRecall can't see to locate. It's a nonessential file that's used to speed up certain indexing operations, and will get rebuilt automatically if it's missing.
- Perform a few captures manually, rather than using actions. If that works, try recreating your actions.

Ralph Strauch wrote:That seems to have taken care of it. Thanks.

Glad to hear it.

I noticed that each qrecall plist has a corresponding plist.locked.

The .plist.locked files are a new feature of Lion. QRecall doesn't create them. I suspect they are filesystem semaphores used to make concurrent access to preferences files more efficient and predictable.

Ralph Strauch wrote:I think I've had problems with beta 41 since I installed it, but that's also around the same time I upgraded to Lion, so that may also have been the source of the problems.

Ralph,

You most definitely have a problem with the scheduler process on your iMac. It's a simple problem, with an easy fix, but I have no idea how or when it happened.

Find the com.qrecall.scheduler.plist file in your ~/Library/Preferences folder and throw it away. This will fix your problem.

The preferences file for your iMac's scheduler had an invalid value for one of the settings. Specifically, when the scheduler shuts down it saves whether the user was currently logged in or out, so when it starts up again it can correctly schedule any actions that might have been waiting for a log in or out event.

The problem is that the value stored in the com.qrecall.scheduler.plist is invalid (neither logged in nor logged out). The beta version of the scheduler takes this as a bad sign, panics, and terminates. OS X's background process management starts it again in 10 seconds and the whole calamity repeats itself. *sigh*

The log file is so full of restart messages that there's not enough history in the diagnostic report to tell when this problem started or what might have precipitated it.

Got it. I'll will put that on the wish list.

What do you want to get out of a QRecall menu extra?

Just a smaller activity display than the monitor window? A way of starting and stopping actions, suspending the schedule, that sort of thing?

Chris Caouette wrote:Not to sidetrack the discussion too much but i'm starting anew with my archives now that Lion is out...and I'm not worried about older versions of files as my current setup is all I need.

What would you like a QRecall menu extra would do?

Steve,

You are having a "bad data" day.

Recap

From your description and the logs, I see that you had a capture fail on July 12 due to the discovery of a corrupted data record. You repaired the archive, which encountered and fixed a corrupted data record, and then went on to preform several more captures without incident.

You then copied the archive to an new volume and performed a couple of more successful captures before encountering the same date record corruption problem on July 15. I see in the logs that you then repaired the (new, copied) archive, but there's not much after that before the report ends.

Bad News

First, the (possibly) bad news. The position of the corrupted data record that caused the capture on July 12 to fail is not the same data record reported by the repair that followed. The record that caused the capture to fail was suddenly OK, while some other record was now found to be bad. (Data just doesn't magically fix itself.) This means that the data corruption does not appear to be on the physical disk. Instead, it's occurring somewhere else, most likely on the trip from the platter to your RAM.

After transferring the archive to the new disk, a capture encountered a new data record that was corrupted. The repair that followed reported no less than 14 damaged records.

Good News

Now that sounds bad, but there's potentially good news here. The bad record that caused the latest capture to fail was also one of the 14 records reported by the repair process. This means the damaged data existed on the physical drive.

So it might be that during the copy from the old drive to the new drive, even more data was mis-read from the old drive and that corrupted data was written to the new drive. If that's that case, and the problem that was causing the old data to be corrupted isn't also afflicting the new drive, then the new archive should be OK now that it's been repaired.

If you encounter a data corruption problem during an action and want to distinguish between data corruption on the physical drive and data corruption caused during transfer, try verifying the archive a few times. If you have a data loss on the physical drive, the verify will stop at the same record position every time. If, on the other hand, the verify is successful, or stops with errors at different records positions, then you are experiencing transient data transfer problems, most likely caused by a flaky disk controller, data bus, motherboard, or possibly even bad RAM.

Anything I can do to help debug this issue?

Steve,

Please send a diagnostic report (Help > Send Report). The report will include all crash logs in addition to other information about what QRecall was doing at the time.

Steve Mayer wrote:I've got an archive whose first layer shows up as "Unknown, Unknown, - Damaged-". I've tried repairing the archive, but this layer stays there

A layer that says it is "-Damaged-" means that it encompasses one or more items that were lost during a repair. This doesn't mean the layer itself is damaged, it means the layer has lost information due to damaged data in the past. Thus, the "damaged" moniker will never go away, no matter how many times you repair the archive.

and I'm not able to delete it or merge it.

You should be able to merge a "-Damaged-" layer just like any other layer. If the items that were damaged have been completely recaptured in subsequent layers, then the "-Damaged-" label will go away (because the newly merged layer is no longer missing any files). If not, the newly merged layer will still be marked as "-Damaged-" because it still contains items that were lost at some point.

Is there a way to remove this layer?

Merge it with a subsequent layer.

It is causing my rolling merge to fail (I believe) with an unknown envelope error.

No, an envelope error is causing your merge to fail. An envelope (checksum) error means that a data record in the archive has become corrupted and means the archive needs to be repaired. I recommend using Disk Utility to repair the volume containing the archive, and then repair the archive itself (using the default repair options).

Secondly, attempting to use the "Copy recovered content to a new archive" option in the Repair menu creates a new empty archive but then proceeds to do nothing that I can tell.

Very strange. That sounds like a bug, which I'll look into.

Is my best option just to delete the damaged archive and start over?

Not necessarily. A "damaged" layer just means that data was lost at some point. It doesn't mean your archive is damaged (well your's sounds like it is, but for a different reason). What is does mean is that you should be mindful when recalling items from this layer because it's missing files.

Gary K. Griffey wrote:I guarantee you...I do not have any partition on my mac named "Griffin"...

No, but I do.

It's the result of a placeholder path that I set up during initial development of the browser. In the case of the reindex, the root path doesn't get set until the index is finished and the archive opens again. Until then, it displays its default path. I never noticed it, because the default path got picked up from my development system, so it's exactly what I would have expected to see.

I just deleted the default path, so now the folder control won't display anything until the reindex finishes and the archive opens.

Ralph,

Please send a full diagnostic report. There's usually some additional log messages, near the ones you copied, that will tell which API QRecall was using and what the error code was.

Thanks!

Bruce,

Yes, there's a new advanced setting that will let you "trick" QRecall into thinking your system has a different amount of physical RAM than it's actually equipped with. Set it with the defaults command in the terminal. For example, to have QRecall size its memory usage to 2GB of RAM, use this command:

defaults write com.qrecall.client QRPhysicalMemoryMB -integer 2048

Note that QRecall will ignore any setting smaller than 512MB or larger than 6GB.

Bruce Giles wrote:With b38, I'm seeing the return of a bug I thought you had squashed.

Not squashed, just semi-random. I have not addressed this bug because I plan to replace it with a different mechanism soon.

I didn't try to do a capture before correcting the preference, so I don't know if it was purely a cosmetic issue, ...

It's purely cosmetic. If you had quit QRecall and relaunched it, I'll wager a dozen Krispy Kreme doughnuts that the window would say that it was now pre-authorized.

When you clicked the "Pre-Authorize" button, it launches a process to permanently authorize the helper tool. This normally involves prompting you for your authorization. It didn't because it was already pre-authorized, so it essentially did nothing and then updated the display.

Gary,

Please send a diagnostic report. If the monitor process is stopping for some reason, that might show up in the log.