First of all, congratulations on the release of version 1.1!

Today, I upgraded our XServe running Tiger Server to QRecall 1.1. Everything seems to have worked perfectly.

I was having no problems under 1.0.1, but I ran a verify before upgrading, just to be sure. After the upgrade, I verified the archive again, and there were no problems. Following that, I re-indexed the archive to take advantage of the Spotlight search capability that was mentioned in the upgrade notes. Finally, I ran a full recapture of the hard drive.

The recapture went very quickly, though I didn't actually time it. After it completed, the archive window reported that the size of the captured layer was about the same as typical recapture runs under 1.0.1. But the number of items captured was over 7000, where it's typically no more than around 300. Is this because it picked up (captured) extended attributes that weren't captured in 1.0.1? Does my upgraded archive now contain everything that it would have had if I had started a new archive instead of upgrading the old one?

Bruce Giles wrote:First of all, congratulations on the release of version 1.1!

Today, I upgraded our XServe running Tiger Server to QRecall 1.1. Everything seems to have worked perfectly.

That's good news.

... After it completed, the archive window reported that the size of the captured layer was about the same as typical recapture runs under 1.0.1. But the number of items captured was over 7000, where it's typically no more than around 300. Is this because it picked up (captured) extended attributes that weren't captured in 1.0.1?

That's very likely. The rules that determine when an item is recaptured changed subtlety between 1.0 and 1.1. It's very likely that you have items with directory information that triggered 1.1 to recapture them. One significant change is that 1.1 will now recapture an item if its attribute modification date changes, even if none of its attributes actually changed.

In these cases, QRecall will recapture the item and store a new metadata record for that item. Since the contents of the files was unlikely to have changed, no new file data is added to the archive — just a new metadata record.

Note that QRecall 1.1 won't recapture an item just because it has extended attributes and the previously captured version doesn't. See the "Utility to recapture items with extended attributes" thread for details.

Does my upgraded archive now contain everything that it would have had if I had started a new archive instead of upgrading the old one?

I don't know how may files you have on that volume, but I'll guess it's more than 7,000. I'm sure there are lots of files which weren't recaptured. If true, then the latest layer is certainly busy, but probably doesn't contain every single item on the volume.

James Bucanek wrote:Note that QRecall 1.1 won't recapture an item just because it has extended attributes and the previously captured version doesn't. See the "Utility to recapture items with extended attributes" thread for details.

I just tried that, but the utility fails to run:

dyld: lazy symbol binding failed: Symbol not found: _realpath$DARWIN_EXTSN

  Referenced from: /Volumes/QRecall Extended Attribute Nudge Utility/./QRTouchXAttrItems

  Expected in /usr/liblibSystem.B.dylib



dyld: Symbol not found: _realpath$DARWIN_EXTSN

  Referenced from /Volumes/QRecall Extended Attribute Nudge Utility/./QRTouchXAttrItems

  Expected in /usr/liblibSystem.B.dylib



Trace/BPT trap

Note that this system is still running Tiger Server, not Leopard Server, if that makes a difference.

Bruce Giles wrote:Note that this system is still running Tiger Server, not Leopard Server, if that makes a difference.

Whoops, that's make a huge difference.

I inadvertently linked the QRTouchXAttrItems tool against the 10.5 SDK instead of the 10.4 SDK.

Download QRTouchXAttrsXItems and try it again. This version should work on 10.4 and 10.5.

James Bucanek wrote:Download QRTouchXAttrsXItems and try it again. This version should work on 10.4 and 10.5.

Yes, that worked. Thanks!