corrupt archive

One of the things that's impressed me about Qrecall has been it's ability to repair damaged archives when that was necessary. I may have exceeded that capability though now, unfortunately. One of my backup drives became unmounted in the middle of a compaction, and that may have become damaged it beyond repair as a result. When I try to mount it or to Repair the archive, Qrecall hangs with an SPOD and won't go any further. Activity Monitor shows Qrecall as unresponsive and using about 0.2% CPU.

Is there anything else I can try, or should I just consider that archive to be toast? Luckily, I have another one so no data is lost.

Ralph

Ralph Strauch wrote:One of the things that's impressed me about Qrecall has been it's ability to repair damaged archives when that was necessary. I may have exceeded that capability though now, unfortunately. One of my backup drives became unmounted in the middle of a compaction, and that may have become damaged it beyond repair as a result.

That, alone, will not irrevocably damage your archive. The compact action moves data in an archive around in a manner that is specifically engineered to avoid any data loss should the action be abnormally terminated. While the archive will need to be repaired, the probability that any information could be lost is extremely small (ilke 1 in 10 million).

When I try to mount it or to Repair the archive, Qrecall hangs with an SPOD and won't go any further.

There's something clearly wrong here, but it's not the repair action.

Activity Monitor shows Qrecall as unresponsive and using about 0.2% CPU.

The QRecall process (aka. the QRecall application) doesn't perform the repair. In fact, it doesn't perform any archive actions. The QRecallHelper process is the faceless process that performs all changes to archives, including repairs. The application's job is to start the background QRecallHelper process, but it doesn't sound like that's happening.

Is there anything else I can try, or should I just consider that archive to be toast?

(1) Send a diagnostic report.
(2) Launch the Activity Monitor application. Enter "QRecall" into the toobar search field (it will make it easier to find QRecall related processes).
(2a) With Activity Monitor running, start the repair.
(2b) If you get a spinning Technicolor pizza of death, select the QRecall process in the Activity Monitor and click on the Sample Process button in the toolbar (Command+Option+S). Save the results to a text file and e-mail that support@qrecall.com.
(2c) See if there's now a QRecallHelper process running.

It gets curiouser and curiouser! I normally keep my backup drives mounted on my wife's iMac and backup my MBP across the network. I was doing the Compact operation on the iMac when it failed. My wife was using the iMac, so I transferred the drive to the MBP to repair it from there. That's where the behavior I described above (Qrecall hanging up) took place. Today, I thought I should send the report you asked for from the computer where the failure initially occurred, so I moved the drive back to the iMac to do the diagnostics you suggested --e xpecting the hanging behavior to be the same on either computer. Much to my surprise, when I mounted the drive on the iMac ,Qrecall recognized it immediately and attempted a pending backup. That failed because of the earlier failure, but I was able to repair the archive successfully, though the log at the end of the repair does indicate one chunk of "invalid data" and a number of "duplicate packages." I followed that up with a routine backup, which seems to be fine. I'm sending you a report covering all that activity.

Is there anything I should do about the problems reported during the repair?

I then mounted the drive on the MBP (over the network from the iMac). The archive opened successfully and I was able to perform a backup there as well. I'll also send a report from the MBP. The interesting thing there, I think, is that that Qrecall log shows no activity between the first failed attempt to open the corrupted archive and the successful backup today. None of the hangs I experienced yesterday show up in the log.

Anyway, things seem back to normal now.

Ralph

Ralph Strauch wrote:It gets curiouser and curiouser!

Indeed.

Is there anything I should do about the problems reported during the repair?

No, this perfectly normal for a repair that follows an interrupted compact action. The compact action works by copying records in the archive so there's no empty space between them. Think of pushing the beads on string all to one end. An archive might start out looking like this:

-1--23-4-5--67--8-9

At the end of the compact action, it will look like this:

123456789----------

If, however, it gets interrupted in the middle of the process, it looks like this:

12345*-4-5--67--8-9

The repair scans from the beginning and finds two problems. First, it encounters a damage record, the result of the interrupted write of record 6. Then it finds a bunch of duplicate records. All of the records have a unique identifier, so it knows they're duplicates. The repair ignores the duplicates and erases them from the archive. After the repair, the archive will look like this:

12345-------67--8-9

You'll notice that all of the original data is still there.

The interesting thing there, I think, is that that Qrecall log shows no activity between the first failed attempt to open the corrupted archive and the successful backup today.

There may have been some underlying problem that was preventing QRecall from launching the QRecallHelper tool. This would explain why no actions were run and the repair "hung" as well.

None of the hangs I experienced yesterday show up in the log.

Sadly, a hang is a stuck process, and a stuck process usually isn't doing anything at all—including logging.

I'll take a look at your diagnostic reports and see if anything jumps out.

Anyway, things seem back to normal now.

That's good.

Ralph Strauch wrote:None of the hangs I experienced yesterday show up in the log.

There's nothing in the QRecall log (because the application was well and truly stuck), but OS X conveniently recorded some .hang files in the DiagnosticReport.

The .hang files show that QRecall was stuck trying create the document window, something that normally happens almost instantaneously. In your case, however, Lion was (inappropriately) trying to create "versions storage" for the archive's document. This is part of Lion's new document versions feature, but there are still bugs in this service that have plagued Lion since it's first release. A number of these bug were fixed in 10.7.3, but clearly not all of them. QRecall archives are not version-able documents, and Lion should never try to make versions of one.

Here's a sample from one of QRecall's attempts to create an archive window in which to start the repair:

14 __-[NSDocumentController openDocumentWithContentsOfURL:display:completionHandler:]_block_invoke_3 + 252 (in AppKit) [0x7fff8b63edcf]

  14 -[NSDocumentController _openDocumentWithContentsOfURL:usingProcedure:] + 530 (in AppKit) [0x7fff8b4d1df9]

	14 __-[NSDocumentController openDocumentWithContentsOfURL:display:completionHandler:]_block_invoke_4 + 648 (in AppKit) [0x7fff8b63f066]

	  14 ??? (in QRecall) [0x100069857]

		14 -[NSDocumentController(NSDeprecated) openDocumentWithContentsOfURL:display:error:] + 810 (in AppKit) [0x7fff8b64ba7e]

		  14 -[NSDocumentController makeDocumentWithContentsOfURL:ofType:error:] + 333 (in AppKit) [0x7fff8b641be8]

			14 ??? (in QRecall) [0x100002134]

			  14 -[NSDocument initWithContentsOfURL:ofType:error:] + 257 (in AppKit) [0x7fff8b4f78f1]

				14 -[NSDocument _initWithContentsOfURL:ofType:error:] + 41 (in AppKit) [0x7fff8b4f7977]

				  14 -[NSDocument _updateRequiresTemporaryVersionStorage] + 89 (in AppKit) [0x7fff8b620af4]

					14 +[NSDocument _temporaryVersionStorageRequiredForURL:] + 33 (in AppKit) [0x7fff8b62adc4]

					  14 GSLibraryCreateForFile + 549 (in GenerationalStorage) [0x7fff8710936d]

						14 ipc_checkin_client + 231 (in GenerationalStorage) [0x7fff870fc045]

						  14 mach_msg_trap + 10 (in libsystem_kernel.dylib) [0x7fff88d6d67a]

You can see that QRecall was stuck in the function GSLibraryCreateForFile, which is Lion's low-level document version storage management.

I don't know if QRecall would have ever come back. Earlier bugs on Lion would cause regular documents to hang for 30-40 seconds when being opened while Lion tried to create version storage for it. But with a document as large as a QRecall archive, who knows how long it would have taken to come back (hours?).

Anyway, the next time you tried this Lion had obviously come to its senses and let you create the document window immediately, choose the repair options, and get on with it.

James Bucanek wrote:
I don't know if QRecall would have ever come back. Earlier bugs on Lion would cause regular documents to hang for 30-40 seconds when being opened while Lion tried to create version storage for it. But with a document as large as a QRecall archive, who knows how long it would have taken to come back (hours?).

Anyway, the next time you tried this Lion had obviously come to its senses and let you create the document window immediately, choose the repair options, and get on with it.

It wasn't so much that Lion came to its senses as it was different behavior on different computers. The hangs were occurring when the drive was connected to the MBP, and the Repair worked when I moved the drive to the iMac. Both machines were running 10.7.3 and beta 59, so there may have been something else on the MBP that contributed to the problem there.

Ralph