QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Numerous failures (icon reference, network/disk errors, lock file)  XML
Forum Index » Problems and Bugs
Author Message
Steven M. Alper



Joined: 05-Mar-07 08:09
Messages: 53
Offline

James:

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:

    which leads to:


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. 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?)

Previous to that I had a compact fail on the same archive with:


And on a different archive, a capture lead to:

which lead to:


Note that this is a different archive, but written on the same drive as the previously mentioned archive.

Like I said, I would not discount the possibility that this is a drive, enclosure, or Firewire controller -caused problem, but I need to start somewhere.

Also, at this time I don't have any disks with enough available space to do a Repair & Copy of the archive.

Thanks!

--

Steven M. Alper
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1473
Offline

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:

    which leads to:


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:

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.

This message was edited 1 time. Last update was at 31-Mar-10 10:05


- QRecall Development -
[Email]
Steven M. Alper



Joined: 05-Mar-07 08:09
Messages: 53
Offline

That's usually a permissions problem, but not always. Without the error code reported I can only guess.


I think I've got the relevant log portion:



James, I thank you again for your devotion to the software and support of your customers.


--

Steven M. Alper
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1473
Offline

Steven M. Alper wrote:I think I've got the relevant log portion:

Nope. This log messages indicates a preallocation (disk full) error.

If you're encountering disk full errors, and your disk isn't full, you might want to read the threads "Leopard/Snow Leopard conflict when backing up to a network drive" and "Preallocation failed".

If this describes your situation, you can disable preallocation entirely by setting QRFilePreallocateDisable—see the post "Advanced QRecall settings"—or try to workaround the bug by changing the QRFilePreallocateBugWorkaroundRule setting.

James, I thank you again for your devotion to the software and support of your customers.


My pleasure.

- QRecall Development -
[Email]
Steven M. Alper



Joined: 05-Mar-07 08:09
Messages: 53
Offline

Ah, yes. My eyes crossed while cross referencing the built-in log with the console log. That was the "cannot convert FSRef to path" problem. I will try the preallocation bug setting changes if it comes up again.

The permissions entries are (I think):


Yep, that's got good-ol' 0x0180.

Thanks!

--

Steven M. Alper
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1473
Offline

Steven M. Alper wrote:The permissions entries are (I think):

BSD error 22 is "invalid argument"—which doesn't make any sense. This usually indicates that the volume structure is corrupt (which can cause the file system to spit out all kinds of nonsense error codes), or the operating system has simply become "confused." A restart will clear up the latter, and a disk repair will usually fix the former.

- QRecall Development -
[Email]
 
Forum Index » Problems and Bugs
Go to:   
Powered by JForum 2.1.8 © JForum Team