In the latest Mountain Lion developer preview (DP4), Apple appears to have fixed the preference value retrieval bug that was causing QRecall to crash. QRecall now seems to be running without incident.

At this point, I'd encourage anyone who is using the Mountain Lion preview to install and test QRecall.

With the release of QRecall 1.2, the QRecall 1.2 beta program is now closed.

A new beta program for QRecall 1.3 will begin soon.

Dawn to Dusk Software is very pleased to announce the release of QRecall 1.2.

With a whole new interface, and dozens of new features and improvements, we're sure you'll enjoy using QRecall even more.

QRecall 1.2 is free upgrade available to users running OS X 10.6 and later. Choose QRecall > Check for updates… from the QRecall application menu, or download it directly.

Steve,

You win this month's obscure bug contest.

You are encountering a problem recovering a file with an unusually large extended attribute. The repair logic is getting tripped up by errors in processing the list of data blocks associated with that extended attribute.

I think I've addressed the problem and have built 1.2.0(82) alpha for you to try. Install 1.2.0a82 and repair the archive again, and then try another capture.

The problem with the extended attribute data appears to be the result of an earlier data corruption. So if you haven't done so already, I'd suggest repairing the volume that contains this archive before you proceed.

Please send another diagnostic report afterwards.

Steve Mayer wrote:So, after deleting the .index files, I tried reindexing the archive. I got an error that while the index had completed, the auto-repair had failed. I tried a capture and that failed after about 2%.

Please send another diagnostic report. I really want to look at the results of that reindex and capture.

Thanks.

Steve Mayer wrote:Using the latest beta(1.2.0(80)rc), I've gotten into a situation where I'm unable to capture anything to my archive any longer as I seem to be stuck in a cycle of Index is bad, repair index, repair, error Index is bad, repair incomplete actions.

Steve,

Your archive has a broken package index file, but I don't know why repair isn't fixing it.

First, please open up a Terminal window and issue the following command, copy the output and send me the results.

ls -l /Volumes/SpawnBackup/SpawnSmayerHome.quanta

Then you might try opening up the SpawnSmayerHome.quanta package, trashing all of the .index files, and then attempt to repair the archive.

In the mean time, I'll look at your log file records in detail.

Ralph Strauch wrote:Are there advantages to doing occasional compactions or does qrecall work just as well with a fragmented archive, so long as there's plenty of free space on the disk?

In general, yes. It won't be as efficient as it could be, but if you have plenty of free disk space then it probably doesn't matter.

Compaction takes a long time, and there doesn't seem much point in doing it unless there are significant advantages.

The most significant benefit is that is keeps your archive compact. This makes verify and repair operations proportionally faster, and there's a slight improvement in performance overall when capturing and merging layers.

Note that a compact action won't completely compact the archive unless there's at least 4% of unused space in the archive to recover. You can increase this threshold by changing the QRCompactFreeSpaceRatioMinimum advanced setting. So you can prevent the archive from doing a time-consuming compaction unless there's at least 10%, 15%, or even 25% of the archive space that's unused.

I don't think I've ever seen an entry for "free" in the archive inspector. All it seems to show is "undetermined."

Following a merge, QRecall don't actually know how much space in the archive is "free" until it performs a process known as garbage collection. This is one of the tasks of the compact action. After a compact, the "free" space value will have a known quantity (until the next merge).

In earlier versions of QRecall, garbage collection was performed at the beginning of every capture. But this turned out to be awkward and too time consuming, so now it's only done by the compact action unless you set the QRCaptureFreeSpaceSweep advanced setting to true.

Yet the status window always shows an amount of "unused space" that seems to get updated regularly.

The status window remembers the last known value until it's updated again.

Are "free" and "unused space" something different, or is the inspector just not picking up the value?

No, it's more like there's a mismatch in terminology. The inspector uses "free" and the status window uses "unused", but it's the same value.

RJ Muna wrote:If I change the name of a folder, will QRecall recognize that change or will it try to back up what it thinks is a new folder?

QRecall organizes items by path, so it will see it as a new folder and capture it.

The folder in question holds 300GB, so if a simple change of the folder name prompts a new 300GB layer in QRecall, it will fill up my backup volume, and the Action will break.

No new data will be added to your archive.

QRecall performs block-level de-duplication. It can't be fooled by renaming, moving, copying, concatenating, appending, or splitting files. If a file contains a block of data that is identical to a block of data that's already been captured (in any other file, on any volume, by any owner), that block of data is not added to the archive again.

Gary,

Thanks for the report. The reindex failed for a completely mundane reason: the archive data is damaged.

So the good news is that it didn't fail because of any weird "no such file" error.

The reindex detected an invalid record during its examination of the primary data file. Since this is on a networked volume, it's not unlikely that this was a transient data error. The simple test is to reindex again and see if the error occurs at the same position in the file.

It could also mean that something has overwritten or corrupted that archive data, in which case a repair is the only way to work around it.

Gary K. Griffey wrote:but the re-index action fails also.

That's even more bizarre. I probably don't have a solution, but I'd still like a diagnostic report that includes the failed reindex.

Gary,

I reviewed the diagnostic report, and it's the same symptom as before. When QRecall is ready to close the archive at the end of the capture, it makes a copy of a small index file and opens the copy; except, the copy can't be found or isn't there (the error -43 you see in the log).

This could be an incompatibility with a rarely used file-duplication function which has caused QRecall to run into problems with other networked file system (including Apple's own AFS).

You could try deleting all of the .index files in the archive's package and then reindexing it. If the problem doesn't go away on its own—like it did last time—I'll take another look at a temporary solution.

I think this problem will go away once QRecall has finished transitioning away from the now-depreciated filesystem APIs in OS X, a task that's planned to be completed before the release of Mountain Lion.

Gary,

Thanks for the diagnostic report. I confirmed what I suspect was happening, and I think I have a fix for it.

Please download and install QRecall 1.2.0a78. After a few days, please send another diagnostic report (regardless of whether the problem reappears or not).

Note that a release candidate will also appear in the next few days, at which time 1.2.0a78 will want to update itself. Please postpone the update until you've let a78 run for a while and have sent the report.

Thanks again,

James

Gary K. Griffey wrote:I am just surprised that some of my other apps have not "bumped their head" on this issue...

You and me both.

I can assume then that only the Capture action attempts to read this Preference value?

Nope. Most of the QRecall processes access numerous user preference values; they read them in different ways, and at different points in their execution. Why this request for this specific value is causing the application to crash is very peculiar.

Gary K. Griffey wrote:I just can't believe that Apple changed that much "under the hood" in 10.8...

They only have to change one thing.

I'm still not sure what the problem is. The capture crashes when it tries to read a user preference value, which is one of the simplest things an application does. I'll file a bug report when I have more info, but for now it remains a mystery.

Gary K. Griffey wrote:Just an update...since loading the last special version that you offered...the "Lost Connection" issue has not occurred.

I'm having the same "problem" here. My Xserve running 10.6.8 that was getting this occationally is now completely silent.

So either the problem has just decided to take a holiday, or the logging code added has subtly altered the timing enough that it changes the outcome of the race condition.

If it doesn't occur by tomorrow, go ahead and send a diagnostic report anyway. I can still review the message timing and see if there's a pattern. I'll probably release a new QRecall beta in a couple of days, without the special debugging code, and we'll see how that does.