QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Checksum Error on Compact  XML
Forum Index » Beta Version
Author Message
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

James,

I created a new archive and performed a capture action of a single folder. The capture completed OK. Next, I ran a Compact action...this failed....a re-index of the archive also failed. Repair of the archive failed too.

The report was sent.

Thanks,

GKG

This message was edited 1 time. Last update was at 10-Dec-11 09:34

James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Online

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.

- QRecall Development -
[Email]
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

James,

Thanks for the info. This Capture, Compact, Repair, etc., was run on a brand new Mac mini server with dual internal drives. 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. I did run Disk Utility on the drive and it came back OK.

I will attempt the capture again...and this time, I will run a Verify action before running the Compact action. I just seem to remember that there was a bug with the Compact action a while back...but I have not seen it recently. I thought this may be a new "strain".

Thanks,

GKG

This message was edited 1 time. Last update was at 10-Dec-11 10:52

James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Online

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.

- QRecall Development -
[Email]
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

I agree about the failures...can happen anytime...

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

In other words, if the folder being captured (on internal drive #1) OR the archive being written to (on internal drive #2) was not read/written normally...the Capture would have flagged the error.

Thanks,

GKG
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Online

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.

- QRecall Development -
[Email]
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

Ok...that makes sense....

I will retry the capture and immediately verify...

Thanks,

GKG
Gary K. Griffey



Joined: 21-Mar-09 10:25
Messages: 156
Offline

James,

Just a follow-up on this...I recreated the archive and have run three subsequent capture/compact/verify actions and they are now running ok.

I am not sure what occurred on the first error...but the issue is no longer present.

Thanks for you feedback...if any other issues occur I will let you know.

At this point...I am seeing no issues with beta 54.

GKG

 
Forum Index » Beta Version
Go to:   
Powered by JForum 2.1.8 © JForum Team