backup failure with 1.1.0.25

I just updated to 1.1.0.25 and did a backup. The activity window is hung at "Stopping" and the log indicates a command failure and incomplete capture. I've opened the archive twice and it doesn't sow the current backup at all. Each time I open it, creates a log entry that the "Archive contains auto-repair information.

I've sent the logs in from the app. You should have them now.

Should I go back to the previous version to rerun the backup?

Ralph

Ralph Strauch wrote:I just updated to 1.1.0.25 and did a backup. The activity window is hung at "Stopping" and the log indicates a command failure and incomplete capture.

It's an interesting problem. The failure is a duplicate entry in the names index. It's relatively harmless, it just happened to trip an internal consistency check in the beta which in turn caused the capture to fail.

The real question is how the duplicate name got there and if it's a legitimate problem or just a side effect of some earlier bug.

If you've got the time, I'd love it if you could create a dump of your archive and send that to me. Open the archive and choose Archive > Dump.... Check the File Packages and Directory Packages options under Data (no need to include the details), and uncheck everything else in the panel. It will take awhile to run, during which the QRecall application will be completely unresponsive. So expect a spinning beach ball for a couple of hours. You can then compress the resulting report file and send that to me.

I've opened the archive twice and it doesn't sow the current backup at all. Each time I open it, creates a log entry that the "Archive contains auto-repair information.

The magic of auto-repair information. If the archive contains an incomplete or failed action, the auto-repair information makes it possible to treat the archive as if the incomplete capture never happened. If you start another capture, merge, or compact action the auto-repair information is used to first roll the archive back to it's previous (presumably pristine) state before the action begins.

I've sent the logs in from the app. You should have them now.

I got those, thanks.

Should I go back to the previous version to rerun the backup?

No, it won't really help. Ideally I'd like to diagnose this problem a little before proceeding, but ultimately I think the problem is in the names index file which isn't critical. A reindex or repair will probably fix it, but I'd still like to know a little more about what's going on before we try that.

I'll run the dump later this afternoon when I've got some time away from the computer. Is this problem at all related to the duplicate entry problem I ran into with v1.1.0.12 (reported in the thread "scheduler gone missing")?

Could the problem be related to the fact that my "Owners and volumes" tab has a duplicate listing for my drive. The duplicate apparently got created back in March, when I first started using qrecall. All the layers that were in it have since been merged into the active listing for that drive, but the duplicate listing remains. I think we discussed this at one point and you said that the duplicate listing wasn't a problem, but I can't find the discussion anywhere. I'm wondering, though, if that is the problem, if I need to dump my current archive altogether and start from scratch?

If any of this would be easier to deal with by phone, my number is xxx-xxx-xxxx and I should be free today from 11-1, and after 2, Pacific Time.

Ralph

Ralph Strauch wrote:I'll run the dump later this afternoon when I've got some time away from the computer. Is this problem at all related to the duplicate entry problem I ran into with v1.1.0.12 (reported in the thread "scheduler gone missing")?

No.

Could the problem be related to the fact that my "Owners and volumes" tab has a duplicate listing for my drive. The duplicate apparently got created back in March, when I first started using qrecall. All the layers that were in it have since been merged into the active listing for that drive, but the duplicate listing remains. I think we discussed this at one point and you said that the duplicate listing wasn't a problem, but I can't find the discussion anywhere.

The "problem" is that you changed identity keys at some point, probably using a trial key then later a permanent (or beta) identity key.

An identity key uniquely identifies the source of captured items. As far as QRecall is concerned, the items captured in the first layer belong to a different owner than the ones in later layers. They don't take up any extra space because the data is shared equally between all captured items. It's just an organizational thing.

And just like volumes in Mac OS X, you can give both of those owners the same name but QRecall will continue to treat them as separate entities.

I'm wondering, though, if that is the problem, if I need to dump my current archive altogether and start from scratch?

No need. I'm planning to add the ability to delete items from an archive, so you should soon be able to delete that owner and rid yourself of the artifact.

If any of this would be easier to deal with by phone, my number is 310-454-8322 and I should be free today from 11-1, and after 2, Pacific Time.

I'd like to look at the dump first. That should tell me if this is a complicated problem or not.

Filename	bu-archive-Dump-0.txt.zip
Description	Archive dump
Filesize	189028 Kbytes
Downloaded	80 time(s)
Download