Numerous failures (icon reference, network/disk errors, lock file)

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:

icon reference does not reference a data package

which leads to:

The archive data is damaged or incomplete....

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:

could not create lock file

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Path: /Volumes/XXX/xxx.quanta/lock

     Permissions: 0x0180

And on a different archive, a capture lead to:

cannot convert FSRef to path

which lead to:

A network or disk error was encountered.

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 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

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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.

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:

2010-03-29 02:00:01.293 -0400 ------- Capture to iTunes (BB2).quanta [2.733860.11197]

2010-03-29 02:00:01.293 -0400 Details archive: /Volumes/WD Green (QR)/iTunes (BB2).quanta [2.733860.11197.4]

2010-03-29 02:00:01.293 -0400 #debug# executing [2.733860.11197.5]

2010-03-29 02:00:01.350 -0400 #debug# preallocation failed [2.733860.11197.6]

2010-03-29 02:00:01.350 -0400 Details preallocation [2.733860.11197.6.1]

2010-03-29 02:00:01.350 -0400 #debug# IO exception [2.733860.11197.6.1.1]

2010-03-29 02:00:01.351 -0400 #debug# API: FSAllocateFork [2.733860.11197.6.1.2]

2010-03-29 02:00:01.352 -0400 #debug# OSErr: -50 [2.733860.11197.6.1.3]

2010-03-29 02:00:01.353 -0400 Details Length: 33554432 [2.733860.11197.6.1.4]

2010-03-29 02:00:01.353 -0400 Details Pos: 70498842360 [2.733860.11197.6.1.5]

2010-03-29 02:00:01.353 -0400 Details File: /Volumes/WD Green (QR)/iTunes (BB2).quanta/repository.data [2.733860.11197.6.1.6]

2010-03-29 02:00:01.353 -0400 #debug# preallocation failed [2.733860.11197.7]

2010-03-29 02:00:01.353 -0400 Details preallocation [2.733860.11197.7.1]

2010-03-29 02:00:01.354 -0400 #debug# IO exception [2.733860.11197.7.1.1]

2010-03-29 02:00:01.354 -0400 #debug# API: FSAllocateFork [2.733860.11197.7.1.2]

2010-03-29 02:00:01.355 -0400 #debug# OSErr: -50 [2.733860.11197.7.1.3]

2010-03-29 02:00:01.355 -0400 Details Length: 2097152 [2.733860.11197.7.1.4]

2010-03-29 02:00:01.356 -0400 Details Pos: 70498842360 [2.733860.11197.7.1.5]

2010-03-29 02:00:01.356 -0400 Details File: /Volumes/WD Green (QR)/iTunes (BB2).quanta/repository.data [2.733860.11197.7.1.6]

2010-03-29 02:00:01.356 -0400 #debug# RepositoryPackage received kPreallocationFailedNotification [2.733860.11197.8]

2010-03-29 02:00:01.532 -0400 Failure Failed [2.733860.11197.9]

2010-03-29 02:00:01.532 -0400 Details cannot convert FSRef to path [2.733860.11197.9.1]

2010-03-29 02:00:01.532 -0400 #debug# IO exception [2.733860.11197.9.1.1]

2010-03-29 02:00:01.532 -0400 #debug# API: FSRefMakePath [2.733860.11197.9.1.2]

2010-03-29 02:00:01.532 -0400 #debug# OSErr: -35 [2.733860.11197.9.1.3]

2010-03-29 02:00:01.537 -0400 #debug# caught exception [2.733860.11197.10]

2010-03-29 02:00:01.538 -0400 Details cannot convert FSRef to path [2.733860.11197.10.1]

2010-03-29 02:00:01.539 -0400 #debug# IO exception [2.733860.11197.10.1.1]

2010-03-29 02:00:01.539 -0400 #debug# API: FSRefMakePath [2.733860.11197.10.1.2]

2010-03-29 02:00:01.539 -0400 Subrosa .Command: capture [2.733860.11197.10.1.3]

2010-03-29 02:00:01.539 -0400 #debug# OSErr: -35 [2.733860.11197.10.1.4]

2010-03-29 02:00:01.539 -0400         Capture failed [2.733860.11197.11]

2010-03-29 02:00:01.540 -0400         A network or disk error was encountered. [2.733860.11197.11.1]

2010-03-29 02:00:01.541 -0400 ------- Capture incomplete (00:00) [2.733860.11197.12]

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

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.

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):

2010-03-29 03:27:00.425 -0400 ------- Compact G5_whole.quanta [2.733860.11416]

2010-03-29 03:27:00.427 -0400 Details archive: /Volumes/WD Green (QR)/G5_whole.quanta [2.733860.11416.5]

2010-03-29 03:27:00.427 -0400 #debug# executing [2.733860.11416.6]

2010-03-29 03:27:04.026 -0400 Failure Failed [2.733860.11416.7]

2010-03-29 03:27:04.027 -0400 Details could not create lock file [2.733860.11416.7.1]

2010-03-29 03:27:04.027 -0400 #debug# IO exception [2.733860.11416.7.1.1]

2010-03-29 03:27:04.027 -0400 #debug# API: createFileAtPath: [2.733860.11416.7.1.2]

2010-03-29 03:27:04.027 -0400 Details Path: /Volumes/WD Green (QR)/G5_whole.quanta/.lock [2.733860.11416.7.1.3]

2010-03-29 03:27:04.028 -0400 #debug# OSErr: 22 [2.733860.11416.7.1.4]

2010-03-29 03:27:04.028 -0400 Details Permissions: 0x0180 [2.733860.11416.7.1.5]

2010-03-29 03:27:04.028 -0400 #debug# Class: RepositoryPackage [2.733860.11416.7.1.6]

2010-03-29 03:27:04.029 -0400 #debug# caught exception [2.733860.11416.8]

2010-03-29 03:27:04.029 -0400 Details could not create lock file [2.733860.11416.8.1]

2010-03-29 03:27:04.029 -0400 #debug# IO exception [2.733860.11416.8.1.1]

2010-03-29 03:27:04.029 -0400 #debug# API: createFileAtPath: [2.733860.11416.8.1.2]

2010-03-29 03:27:04.029 -0400 Details Path: /Volumes/WD Green (QR)/G5_whole.quanta/.lock [2.733860.11416.8.1.3]

2010-03-29 03:27:04.030 -0400 Subrosa .Command: compact [2.733860.11416.8.1.4]

2010-03-29 03:27:04.030 -0400 #debug# OSErr: 22 [2.733860.11416.8.1.5]

2010-03-29 03:27:04.030 -0400 Details Permissions: 0x0180 [2.733860.11416.8.1.6]

2010-03-29 03:27:04.030 -0400 #debug# Class: RepositoryPackage [2.733860.11416.8.1.7]

2010-03-29 03:27:04.031 -0400         Compact failed [2.733860.11416.9]

2010-03-29 03:27:04.031 -0400         A network or disk error was encountered. [2.733860.11416.9.1]

2010-03-29 03:27:04.031 -0400 ------- Compact incomplete (00:00) [2.733860.11416.10]

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

Thanks!

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

2010-03-29 03:27:04.027 -0400 Details could not create lock file

2010-03-29 03:27:04.027 -0400 #debug# IO exception

2010-03-29 03:27:04.027 -0400 #debug# API: createFileAtPath:

2010-03-29 03:27:04.027 -0400 Details Path: /Volumes/WD Green (QR)/G5_whole.quanta/.lock

2010-03-29 03:27:04.028 -0400 #debug# OSErr: 22

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.