I am starting to think there's a major issue with QRecall and network volumes. I just can't get it to work reliably. I've changed client and server. Everytime the archive ends up corrupted.

Here's the log of my last attempt. I will give it yet another try with the latest version!

The problem reported in your log file doesn't have anything to do with network volumes.

It has everything to do with the fact that QRecall is terminating because it discovered two identical files in the same directory -- something that should be impossible.

2007-10-13 20:38:04.255 +0200 Caution Problems processing items
2007-10-13 20:38:04.256 +0200 Details duplicate file
2007-10-13 20:38:04.256 +0200 Details Path: Gonzo:Users:fred:Programs:Temp
2007-10-13 20:38:04.256 +0200 Failure Could not process folder Temp
2007-10-13 20:38:06.554 +0200 Failure Program exception
2007-10-13 20:38:06.554 +0200 Details duplicate file
2007-10-13 20:38:06.554 +0200 Details NSInternalInconsistencyException exception
2007-10-13 20:38:06.555 +0200 Command failed
2007-10-13 20:38:06.555 +0200 An internal program error occured. Please report this problem to the developer.

The latest version of QRecall will probably work, simply because I removed this exception check recently. (After running QRecall for over a year without ever encountering this exception, I concluded that it couldn't happen; I was clearly wrong.)

First, lets start by determining if you do, in fact, have a duplicate directory entry. Would you mind listing the following two directories and sending me the results (via private e-mail if you prefer)?

ls -1 /Users/fred/Programs > ~/Desktop/QRecallTest.txt
ls -1 /Users/fred/Programs/Temp >> ~/Desktop/QRecallTest.txt

Correction, make those commands

ls -A1 /Users/fred/Programs > ~/Desktop/QRecallTest.txt
ls -A1 /Users/fred/Programs/Temp >> ~/Desktop/QRecallTest.txt

It occurred to me that the duplicate file could be hidden.

&gtThe problem reported in your log file doesn't have
&gtanything to do with network volumes.

Another wrong guess

&gtmake those commands

Here you go:

imac24:~ fred$ ls -A1 /Users/fred/Programs
.DS_Store
Godot
Internal
Lopez
Temp
WebKit
bin
lua-5.1.2

imac24:~ fred$ ls -A1 /Users/fred/Programs/Temp
.DS_Store
calimero-1.4
html
mh
pvb
webcore - Doxyfile
imac24:~ fred$


Note that these directories contain svn things that do change quite a bit, potentially even during captures. I may also have moved things.

Thanks

Fred

Frederic Thomas wrote:Another wrong guess

It's not a guess. That error only occurs in one location in the application, and it guards against recording two file records with the same name in the same directory record.

Note that these directories contain svn things that do change quite a bit, potentially even during captures. I may also have moved things.

Does this error occur every time you try to capture this volume/folder, or has it only occurred while the directories were being modified at the same time?

Another good question to get out of the way: Is this the same error you've received in the past, or is this the first time it's occurred? (The log files you posted only recorded one failed capture.)

If this error is consistent, try capturing and recapturing the volume/folder with the latest version and let me know how that works.

I also noticed a couple of other odd things in your log file. Could you check your ~/Library/Logs/CrashReporter/ folder for any recent crash logs? Could you also verify that you have only once instance of the QRecallScheduler process running?

James Bucanek wrote:

Frederic Thomas wrote:Another wrong guess

It's not a guess.

I meant from attributing it to network volumes.

Does this error occur every time you try to capture this volume/folder, or has it only occurred while the directories were being modified at the same time? Another good question to get out of the way: Is this the same error you've received in the past, or is this the first time it's occurred?

I've had a similar error (archive ends up corrupted after 1-2 days) everytime I have tried to use QRecall to backup my machines on network volumes.

If this error is consistent, try capturing and recapturing the volume/folder with the latest version and let me know how that works.

Initial capture went OK (with new version). Trying a second one to check now (so the attached log will contain a partial capture at the end).

I also noticed a couple of other odd things in your log file. Could you check your ~/Library/Logs/CrashReporter/ folder for any recent crash logs?

Attached.

Could you also verify that you have only once instance of the QRecallScheduler process running?

imac24:~ fred$ ps -ax | grep QRecall
278 ?? S 0:00.22 /Applications/QRecall.app/Contents/Resources/QRecallMonitor.app/Contents/MacOS/QRecallMonitor -psn_0_2097153
337 ?? S 0:00.08 /Users/fred/Library/Application Support/QRecall/QRecallScheduler
828 p1 S+ 0:00.00 grep QRecall


That said, upgrading to the new version did not happen smoothly, see attached log. QRecall kept on complaining about the scheduler not being the same version, or something. Seems OK now. Given it was beta to beta upgrade and I was chasing the other problem, I did not pay too much attention...

Attaching here the crashlog, the forum SW seems to be a bit flaky when it comes to attachements.

Also, after re-reading the release notes, maybe I should mention the directory ~/Programs/Temp/html contains 42'110 items.

Frederic Thomas wrote:

James Bucanek wrote:

Frederic Thomas wrote:Another wrong guess

It's not a guess.

I meant from attributing it to network volumes.

Sorry, I misinterpreted that. My bad.

I've had a similar error (archive ends up corrupted after 1-2 days) everytime I have tried to use QRecall to backup my machines on network volumes.

If you have a directory with 40,000 items in it, then that could be explained by a different bug.

Could you also verify that you have only once instance of the QRecallScheduler process running?

imac24:~ fred$ ps -ax | grep QRecall
278 ?? S 0:00.22 /Applications/QRecall.app/Contents/Resources/QRecallMonitor.app/Contents/MacOS/QRecallMonitor -psn_0_2097153
337 ?? S 0:00.08 /Users/fred/Library/Application Support/QRecall/QRecallScheduler
828 p1 S+ 0:00.00 grep QRecall

That's good.

That said, upgrading to the new version did not happen smoothly, see attached log. QRecall kept on complaining about the scheduler not being the same version, or something. Seems OK now. Given it was beta to beta upgrade and I was chasing the other problem, I did not pay too much attention...

It should complain exactly once: After the upgrade, the client doesn't match the version of the running scheduler so it tells it to quit and restarts the new one. If you have multiple messages to this effect, then I suspect that you had multiple instances of the scheduler running (which would explain some other odd things in the log). The upgrade probably fixed the problem by telling all of the old schedulers to quit.

So getting back to the original problem: The key will be to watch the captures over the next few days. If you can successfully take multiple captures of the folder with 40,000 items, then I think your problems should be resolved.

The duplicate file issue shouldn't crop up again, because the current version doesn't care. While it shouldn't be possible to have two files with the same name, QRecall should deal with the situation gracefully. (From QRecall's perspective, this isn't much different than having two files that differ only in case captured from a case-preserving filesystem and restored to a case-insensitive filesystem.)

The issue of having 40,000 files in a subdirectory could definitely have contributed to directory synchronization problems for that directory and its parent. It would take so long to process that one huge subdirectory that it and its parent could easily have time to change before the capture was done. If this is the case, the latest version is much less likely to encounter this problem. The improvements to the handling of large directories has improved the speed of QRecall so much, that it's literally over a 1,000 times faster for folders this large. So there's much (much!) less time for concurrent changes to confuse the capture.

If everything runs smoothly for a week or so, the interesting thing to look at would be to dump the directory structure of the archive and look for duplicate file records.

So... It worked fine for a while: single mac capturing things to an archive. It does it at the scheduled time (or later). It mounts the network volume. Fine.

So next step was to backup another machine on the same volume/archive. Got another key. 3 volumes to capture.

Only thing is the captures this time are huge, 200+ GB... and so it takes a while to perform, but they are all scheduled at the same time.

The first capture eventually finished. The second stopped because "there was not enough memory". The third dutifully waited until the first finished... only to stop with an archive integrity error. On the other mac, the backup waited for the third capture to fail to fail as well. So the archive is being repaired as we speak.

I have a log file of 69 MB which mainly contains endless repetitions of (the file changes, of course):

2007-10-25 21:56:39.110 +0200 Curious No file icon [2.732974.25150.18.9]
2007-10-25 21:56:39.110 +0200 Details missing file icon [2.732974.25150.18.9.1]
2007-10-25 21:56:39.110 +0200 Details IO exception [2.732974.25150.18.9.1.1]
2007-10-25 21:56:39.111 +0200 Details File: System:Libraryrinters:EPSON:LaserPrinter:CommonageLibraries:usbepson.framework:Versions:A:usbepson [2.732974.25150.18.9.1.2]
2007-10-25 21:56:39.111 +0200 Curious No folder icon [2.732974.25150.18.10]
2007-10-25 21:56:39.111 +0200 Details missing folder icon [2.732974.25150.18.10.1]
2007-10-25 21:56:39.111 +0200 Details IO exception [2.732974.25150.18.10.1.1]
2007-10-25 21:56:39.111 +0200 Details Folder: System:Libraryrinters:EPSON:LaserPrinter:CommonageLibraries:usbepson.framework:Versions:A [2.732974.25150.18.10.1.2]
2007-10-25 21:56:39.115 +0200 Curious Could not obtain icon [2.732974.25150.30]
2007-10-25 21:56:39.115 +0200 Details error obtaining icon [2.732974.25150.30.1]
2007-10-25 21:56:39.116 +0200 Details IO exception [2.732974.25150.30.1.1]
2007-10-25 21:56:39.116 +0200 Details File: Current [2.732974.25150.30.1.2]
2007-10-25 21:56:39.116 +0200 #debug# API: GetIconRefFromFileInfo [2.732974.25150.30.1.3]
2007-10-25 21:56:39.116 +0200 #debug# OSErr: -2582 [2.732974.25150.30.1.4]
2007-10-25 21:56:39.117 +0200 Curious No file icon [2.732974.25150.18.11]
2007-10-25 21:56:39.118 +0200 Details missing file icon [2.732974.25150.18.11.1]
2007-10-25 21:56:39.118 +0200 Details IO exception [2.732974.25150.18.11.1.1]
2007-10-25 21:56:39.118 +0200 Details File: System:Libraryrinters:EPSON:LaserPrinter:CommonageLibraries:usbepson.framework:Versions:Current [2.732974.25150.18.11.1.2]
2007-10-25 21:56:39.119 +0200 Curious No folder icon [2.732974.25150.18.12]
2007-10-25 21:56:39.119 +0200 Details missing folder icon [2.732974.25150.18.12.1]
2007-10-25 21:56:39.119 +0200 Details IO exception [2.732974.25150.18.12.1.1]
2007-10-25 21:56:39.119 +0200 Details Folder: System:Libraryrinters:EPSON:LaserPrinter:CommonageLibraries:usbepson.framework:Versions [2.732974.25150.18.12.1.2]
2007-10-25 21:56:39.122 +0200 Curious Could not obtain icon [2.732974.25150.31]
2007-10-25 21:56:39.122 +0200 Details error obtaining icon [2.732974.25150.31.1]
2007-10-25 21:56:39.122 +0200 Details IO exception [2.732974.25150.31.1.1]
2007-10-25 21:56:39.123 +0200 Details File: Resources [2.732974.25150.31.1.2]
2007-10-25 21:56:39.123 +0200 #debug# API: GetIconRefFromFileInfo [2.732974.25150.31.1.3]
2007-10-25 21:56:39.124 +0200 #debug# OSErr: -2582 [2.732974.25150.31.1.4]

and finishes with

2007-10-25 22:50:25.448 +0200 Curious No file icon [2.732974.25150.18.75470]
2007-10-25 22:50:25.448 +0200 Details missing file icon [2.732974.25150.18.75470.1]
2007-10-25 22:50:25.448 +0200 Details IO exception [2.732974.25150.18.75470.1.1]
2007-10-25 22:50:25.448 +0200 Details File: System:var [2.732974.25150.18.75470.1.2]
2007-10-25 22:50:25.514 +0200 #debug# -[DataHash preloadHashCache] stopped [2.732974.25150.75488]
2007-10-25 22:51:12.999 +0200 #debug# -[NegativeChecksumMap dealloc] unmapped/closed, 536870912 bits, 11708025 trues [2.732974.25150.75489]
2007-10-25 22:51:13.064 +0200 Failure Failed [2.732974.25150.75490]
2007-10-25 22:51:13.064 +0200 Details error getting generic folder icon [2.732974.25150.75490.1]
2007-10-25 22:51:13.064 +0200 Details NSInternalInconsistencyException exception [2.732974.25150.75490.1.1]
2007-10-25 22:51:13.066 +0200 Failure Program exception [2.732974.25150.75491]
2007-10-25 22:51:13.068 +0200 Details error getting generic folder icon [2.732974.25150.75491.1]
2007-10-25 22:51:13.069 +0200 Details NSInternalInconsistencyException exception [2.732974.25150.75491.1.1]
2007-10-25 22:51:13.069 +0200 Command failed [2.732974.25150.75492]
2007-10-25 22:51:13.069 +0200 An internal program error occurred. Please report this problem to the developer. [2.732974.25150.75492.1]
2007-10-25 22:51:13.070 +0200 ------- Capture incomplete (1:23:20) [2.732974.25150.75493]
2007-10-25 22:51:13.081 +0200 #debug# command returned exception [4.732974.17469.9]
2007-10-25 22:51:13.081 +0200 Details error getting generic folder icon [4.732974.17469.9.1]
2007-10-25 22:51:13.081 +0200 Details NSInternalInconsistencyException exception [4.732974.17469.9.1.1]
2007-10-25 22:51:13.083 +0200 #debug# command returned exception [3.732974.17499.39]
2007-10-25 22:51:13.083 +0200 Details error getting generic folder icon [3.732974.17499.39.1]
2007-10-25 22:51:13.084 +0200 Details NSInternalInconsistencyException exception [3.732974.17499.39.1.1]
2007-10-25 22:51:13.093 +0200 #debug# stopped [2.732974.25150.75494]
2007-10-25 22:51:19.094 +0200 #debug# CaptureCommand has no listeners, terminating process [2.732974.25150.75495]
2007-10-25 22:51:20.120 +0200 #debug# -[QRUserBSDSocketPath deleteSocket] /var/tmp/QRecall.501/QRecallHelper.243c9869 [2.732974.25150.75496]
2007-10-25 22:59:01.586 +0200 #debug# -[QRUserBSDSocketPath connectPort] /var/tmp/QRecall.501/QRecallScheduler [3.732974.25207.1]
2007-10-25 22:59:03.102 +0200 #debug# QuantumScheduler exiting with status 0 [3.732974.25207.2]

Need the log ? It's only 5.4 MB zipped. Or I can cut the middle stuff.

Fred

Fred,

Thanks for the detailed problem report.

The "Could not obtain icon" and "No file icon" messages are exceptional, but not problematic. These messages mean that QRecall asked the operating system for the icon to display for these particular items and the operating system said it doesn't have one or couldn't find one. Odd, but nothing serious. It might suggest that your launch services database needs resetting. This can be done via the command-line and I'm sure there are free-ware utilities that will do this also.

Now, the shocking problem is the "error getting generic folder icon" failure. This simply should never, ever, happen and why it's coded as an exception in QRecall. This is thrown when QRecall asks Mac OS X for the generic document and folder icons for use document/folders that don't have a custom icon.

These should be static resources in the operating system, and the OS should always return them. Something is amiss here.

Clearly QRecall needs to deal with this situation gracefully. I'll fix QRecall to handle this situation. In the mean time, I'd consider reinstalling the OS on that computer.

James Bucanek wrote:In the mean time, I'd consider reinstalling the OS on that computer.

Huh ? I mean, it works fine - sounds very drastic. And it did capture 250GB all right. Just in case, it's Mac OS X SERVER, if that makes any difference?

I have rebooted the machine and will try again the capture on a new archive.

Fred

Also, I've now spent about 48 hours reindexing and repairing the archive but it still fails to backup to it (the computer that used to work).

Once you have 2-3 machines having N drives all backuping to the same shared archive, changing the archive everytime Qrecall thinks it has a problem is a pain.

I *still* think the archives are too fragile. Something goes wrong and boom, there goes your archive.

Fred

OK, so here's the log on the machine that repaired the archive:

2007-10-26 17:59:04.427 +0200 ------- Repair imac24.quanta [2.732975.15361]

...

2007-10-27 02:48:16.927 +0200 #debug# sorting 3448877 hash entries [2.732975.15361.16]
2007-10-27 02:48:38.837 +0200 #debug# writing 3448877 new hash entries, flushing 0 [2.732975.15361.18]
2007-10-27 02:58:10.340 +0200 #debug# hash contains 11837484 entries [2.732975.15361.19]
2007-10-27 02:58:10.420 +0200 #debug# -[DataHash closeNegativeHashMap] writing RAM map to file; size 67108864, path /Volumes/RetroCPQrec/imac24.quanta/negative.index [2.732975.15361.20]
2007-10-27 02:58:11.309 +0200 #debug# -[NegativeChecksumMap writeMapFileAtPath:] wrote 8388612 bytes to /Volumes/RetroCPQrec/imac24.quanta/negative.index, result=YES, trues=10852949 [2.732975.15361.21]
2007-10-27 02:58:12.958 +0200 #debug# FillMap: 70047 holes, 22960968 free (22960968 clean, 0 trashy) [2.732975.15361.22]
2007-10-27 02:58:13.870 +0200 #debug# -[NegativeChecksumMap dealloc] released, 67108864 bits, 10852949 trues [2.732975.15361.23]
2007-10-27 02:58:13.996 +0200 ------- Repair finished (8:59:0 [2.732975.15361.24]


Note it says "REPAIR COMPLETE". But apparently I just waited a 8 hours of my life for nothing, as capturing again:

2007-10-27 03:52:32.259 +0200 ------- Capture to imac24.local.quanta [2.732976.488]
2007-10-27 03:52:32.259 +0200 Details archive: /Volumes/RetroCPQrec/imac24.local.quanta [2.732976.488.5]
2007-10-27 03:52:32.259 +0200 #debug# executing [2.732976.488.6]
2007-10-27 03:52:32.260 +0200 #debug# -[RepositoryCommand prepareRepositoryUsing:] alias reference invalid, path RetroCPQrec:imac24.local.quanta [2.732976.488.7]
2007-10-27 03:52:32.261 +0200 #debug# -[RepositoryCommand prepareRepositoryUsing:] no listeners that will resolve alias [2.732976.488.8]
2007-10-27 03:52:32.761 +0200 #debug# -[ProgressManager resolveReferenceRequest:] RetroCPQrec:imac24.local.quanta [4.732976.477.4]
2007-10-27 03:52:32.762 +0200 #debug# -[ProgressManager _resolveReference:] RetroCPQrec:imac24.local.quanta [4.732976.477.5]
2007-10-27 03:52:32.762 +0200 #debug# -[RepositoryCommand prepareRepositoryUsing:] requested resolution; waiting for results [2.732976.488.9]
2007-10-27 03:52:33.739 +0200 #debug# -[DiskArbitrationSteward volumeMountNotification:] mounted volume /Volumes/RetroCPQrec [3.732976.485.8]
2007-10-27 03:52:33.771 +0200 #debug# discovered recent 'imac24.quanta', mod=2007-10-24 22:52:12 +0200, repository=/Volumes/RetroCPQrec/imac24.quanta [4.732976.477.6]
2007-10-27 03:52:33.773 +0200 #debug# -[RepositoryCommand didResolveRepositoryRef] [2.732976.488.10]
2007-10-27 03:52:33.899 +0200 #debug# -[NegativeChecksumMap initMappedToPath:] mapped to /Volumes/RetroCPQrec/imac24.quanta/negative.index, 8388608 bytes, 67108864 bits, 10852949 trues [2.732976.488.11]
2007-10-27 03:52:33.899 +0200 #debug# -[DataHash loadNegativeHashMap] discovered existing map; size 67108864, path /Volumes/RetroCPQrec/imac24.quanta/negative.index [2.732976.488.12]
2007-10-27 03:52:33.902 +0200 #debug# -[NegativeChecksumMap dealloc] unmapped/closed, 67108864 bits, 10852949 trues [2.732976.488.13]
2007-10-27 03:52:33.905 +0200 #debug# -[DataHash loadNegativeHashMap] alloc empty map; size 1073741824 [2.732976.488.14]
2007-10-27 03:52:34.127 +0200 #debug# -[NegativeChecksumMap initWithCapacity:] in memory, 134217732 bytes, 1073741824 bits, 0 trues [2.732976.488.15]
2007-10-27 03:52:37.789 +0200 #debug# terminating Client-1.0.0b(4-Oct 21 2007 [1.732976.472.22]
2007-10-27 03:53:00.862 +0200 #debug# -[QRUserBSDSocketPath connectPort] /var/tmp/QRecall.501/QRecallScheduler [3.732976.492.1]
2007-10-27 03:53:02.365 +0200 #debug# QuantumScheduler exiting with status 0 [3.732976.492.2]
2007-10-27 03:55:06.206 +0200 #debug# -[DataHash loadNegativeHashMap] rebuilt negative map from hash; refill=YES, 11772756 trues, 11837485 cached entries [2.732976.488.16]
2007-10-27 03:55:06.208 +0200 #debug# -[HashFile anticipateHashGrowth:] total free=321586511872, practicalGrowth=11776849, maxGrowth=21716947, hashEntries=11837484, hashSize=134217728 [2.732976.488.17]
2007-10-27 03:55:06.208 +0200 #debug# growth of 11776849 entries will not cause hash to exceed 134217728 entries [2.732976.488.18]
2007-10-27 03:59:00.515 +0200 #debug# -[QRUserBSDSocketPath connectPort] /var/tmp/QRecall.501/QRecallScheduler [3.732976.511.1]
2007-10-27 03:59:02.016 +0200 #debug# QuantumScheduler exiting with status 0 [3.732976.511.2]
2007-10-27 04:12:14.599 +0200 #debug# -[NegativeChecksumMap dealloc] released, 1073741824 bits, 11772756 trues [2.732976.488.19]
2007-10-27 04:12:14.640 +0200 Failure Failed [2.732976.488.20]
2007-10-27 04:12:14.640 +0200 Details invalid envelope type [2.732976.488.20.1]
2007-10-27 04:12:14.640 +0200 Details Data exception [2.732976.488.20.1.1]
2007-10-27 04:12:14.640 +0200 Details Length: 766761 [2.732976.488.20.1.2]
2007-10-27 04:12:14.640 +0200 Details Type: 1644167168 [2.732976.488.20.1.3]
2007-10-27 04:12:14.640 +0200 Details Pos: 213911357848 [2.732976.488.20.1.4]
2007-10-27 04:12:14.640 +0200 #debug# Caught exception [2.732976.488.21]
2007-10-27 04:12:14.641 +0200 Details invalid envelope type [2.732976.488.21.1]
2007-10-27 04:12:14.641 +0200 Details Data exception [2.732976.488.21.1.1]
2007-10-27 04:12:14.641 +0200 Details Length: 766761 [2.732976.488.21.1.2]
2007-10-27 04:12:14.641 +0200 Details Type: 1644167168 [2.732976.488.21.1.3]
2007-10-27 04:12:14.641 +0200 Subrosa .Command: capture [2.732976.488.21.1.4]
2007-10-27 04:12:14.641 +0200 Details Pos: 213911357848 [2.732976.488.21.1.5]
2007-10-27 04:12:14.641 +0200 Capture failed [2.732976.488.22]
2007-10-27 04:12:14.641 +0200 A data integrety problem in the archive was encountered. Consider reindexing or repairing the archive. [2.732976.488.22.1]
2007-10-27 04:12:14.641 +0200 ------- Capture incomplete (17:07) [2.732976.488.23]

Fred

First let me say that I'm extremely perplexed and upset about this situation. I can't come up with any scenarios to explain why an archive that passes a repair could contain a package with an invalid type (which is what the logs are reporting).

Given the other evidence, I have to assume that it's somehow related to the missing icon data that was reported in your earlier report. I'll try to simulate the same errors and see if I can reproduce the problem here.

You'll obviously have to repair the archive again before it can be used. After the repair, it would be useful to perform a verify. That would tell a lot about the integrity of the archive before anything else is done to it.

When diagnosing problems like this, the next step would be to produce a dump of the archive and analyze that. However, dumps of large archives can, themselves, be very large. Trying to send me a copy of the dump could be impractical.

It won't tell us what's going wrong, but you can probably reclaim the use of the archive by deleting all of the recent layers added by the systems that were encountering the capture problems. Performing a compact after the delete should clear out all of the detritus and allow you to capture your original system to the archive once again.

QRecall has not been tested on Mac OS X Server. There may be lurking compatibility issues which are at the root of this problem.

I forgot to mention in the previous post, please send me those log files. I'd like to examine them for any additional clues about the missing icon problems.

The comment I made about reinstalling the OS was based entirely on my experience with OS X, not OS X Server. The call that's caused your capture problem has never failed on any regular system I've ever encountered.

OS X Server appears to "think different" when it comes to the launch services database.

I'd very much like to get more feedback from users that are using QRecall to capture multiple systems to a single archive. For the time being, would it be a terrible inconvenient to limit your multi-system use to just OS X client systems? The more I think about this problem the more I suspect an incompatibly with OS X Server which could be tested/confirmed by capturing to its own archive. This would be a smaller problem to examine and wouldn't interfere with the backups of your other systems.