Steven M. Alper wrote:I'm seeing repeated failures to multiple archives. As we've seen in the past it's probable that QRecall is not the cause, but I'm hoping we can eliminate it before I turn to other more expensive options.
The reported problems range from:
icon reference does not reference a data package
which leads to:
The archive data is damaged or incomplete....
Steve,
This is a bug in QRecall. The repair command doesn't check the icon references of directories, which means that even after a repair the archive will fail verification. The good new is that this is entirely a cosmetic problem; the icon reference is simply so that QRecall can display the same folder image that the Finder does. It doesn't have any impact on the actual file data stored in the archive.
This has been fixed in 1.2b1, which I will get out
real soon.
This is, of course, my big archive at about 237gb. I have run repairs on the archive which have always completed successfully, leaving a "Damaged" layer that does not seem to be delete-able.
You can't delete a damaged layer, but you can merge it with subsequent layers. A damaged layer is missing information which subsequent layers may have recaptured. Personally, I'd leave this layer alone until 1.2 is available. I've recently made significant enhancements and fixed a number of bugs related to the repair, merging, and recapturing of items with damaged layers.
Last night I had a verify with the "icon reference" error, followed by a successful capture. (Why doesn't a verify failure prevent further unattended actions on an archive?)
This is somewhat of semantic decision. The Verify opens the archive read-only, so (by definition) it can't modify the archive in any way, which would include changing it so that subsequent actions wouldn't run. And in your case it's a good thing, because the verify is reporting an error that repair won't fix, so you'd really be stuck if verify made your archive unusable.
In general, actions like capture, compact, and merge check what they need to check as they work. If anything is amiss, they will immediately stop using the archive to avoid corrupting the data in the archive. But if they don't encounter any problems, then more than likely they haven't made anything worse than it already was.
Previous to that I had a compact fail on the same archive with:
could not create lock file
Path: /Volumes/XXX/xxx.quanta/lock
Permissions: 0x0180
That's usually a permissions problem, but not always. Without the error code reported I can only guess.
The rest of the errors you report are typically caused by a corrupted volume or transient communication errors. I would suggest that you repair the volume using Disk Utility or your favorite drive repair software. If the repair reports any problems, then verify/repair the archive.