Joel wrote:Is there a way to fix? I haven't restarted as the guy said above. Should I just try that?

If you're running Leopard, then a restart will probably fix it. Alternatively, you could uninstall QRecall (hold down the Shift+Option keys and choose QRecall > Quick and Uninstall, restart QRecall, then go to Preferences and reauthorize it).

Regardless, please send a diagnostic report (Help > Send Report...) so that I can (hopefully) determine why the scheduler stopped running in the first place.

QRecall Extended Attribute Nudge Utility
Download: http://www.qrecall.com/release/QRecallNudge.dmg

QRecall version 1.1.0(25) beta introduced the ability to capture and restore extended attributes. Items captured with 1.1.0(25) or later will include extended attribute information.

However, QRecall only captures items that are new or have changed. An item captured with a pre-1.1.0(25) version will not contain any extended attribute information, but that same item won't be recaptured (capturing its extended attribute information) until it changes.

The QRTouchXAttrItems tool is a simple command line executable that will fix this problem. It searches a directory tree for any item that has extended attributes and "touches" it. QRecall will then recapture the item the next time a capture is performed.

To use the tool, open a Terminal window and execute the tool from the command line. The tool expects a single parameter which is the directory to scan.

The tool must have access to the items it is scanning, so run it using sudo to touch items that you don't own.

For example, to scan the entire boot volume:

cd /Volumes/QRecall\ Extended\ Attribute\ Nudge\ Utility/

sudo ./QRTouchXAttrItems /

The tool will scan the entire directory tree for any item that has one or more extended attributes. When it finds one it will "nudge" (add one second to) its last modification date. This is enough to convince QRecall that the item has changed and needs to be recaptured.

QRTouchXAttrItems will ignore all special file types (block devices, pipes, etc.) and does not traverse symbolic links.

There's a serious bug in the 1.1.0(25) beta version that affect Intel-based users. If the archive contains extended attribute information, a byte-order bug could literally scramble the archive.

All users who have version 1.1.0(25) or later are strongly encouraged to upgrade to 1.1.0(27) immediately.

Steve,

This is a known bug, discovered about 8 hours after 1.1.0(25) was released.

QRecall has some overly zealous internal consistency checks that are causing the capture to fail if you have items with extended attributes that contain no data. QRecall (read "me")) just didn't expect that to happen.

1.1.0(26) was should handle zero-length extended attributes gracefully. You can download 1.1.0(26) (http://www.qrecall.com/release/QRecall_1.1.0b26.dmg) and give it a try now.

Usual rules for replacing a beta version by hand:

1) Download the 1.1.0(26) disk image http://www.qrecall.com/release/QRecall_1.1.0b26.dmg
2) Open your Applications folder
3) Drag the old QRecall to the trash
4) Open the disk image and drag the new QRecall into the Applications folder
5) Open the new QRecall in the Applications folder.

Please let me know if you have any problems. I've had one report of installation errors when upgrading manually from 1.1.0(25) to 1.1.0(26).

If you do have upgrade issues, try uninstalling QRecall (Hold down Shift+Option and choose QRecall > Quit and Uninstall). Then launch QRecall again, go to the Preferences, and reauthorize.

Ralph Strauch wrote:I'll run the dump later this afternoon when I've got some time away from the computer. Is this problem at all related to the duplicate entry problem I ran into with v1.1.0.12 (reported in the thread "scheduler gone missing")?

No.

Could the problem be related to the fact that my "Owners and volumes" tab has a duplicate listing for my drive. The duplicate apparently got created back in March, when I first started using qrecall. All the layers that were in it have since been merged into the active listing for that drive, but the duplicate listing remains. I think we discussed this at one point and you said that the duplicate listing wasn't a problem, but I can't find the discussion anywhere.

The "problem" is that you changed identity keys at some point, probably using a trial key then later a permanent (or beta) identity key.

An identity key uniquely identifies the source of captured items. As far as QRecall is concerned, the items captured in the first layer belong to a different owner than the ones in later layers. They don't take up any extra space because the data is shared equally between all captured items. It's just an organizational thing.

And just like volumes in Mac OS X, you can give both of those owners the same name but QRecall will continue to treat them as separate entities.

I'm wondering, though, if that is the problem, if I need to dump my current archive altogether and start from scratch?

No need. I'm planning to add the ability to delete items from an archive, so you should soon be able to delete that owner and rid yourself of the artifact.

If any of this would be easier to deal with by phone, my number is 310-454-8322 and I should be free today from 11-1, and after 2, Pacific Time.

I'd like to look at the dump first. That should tell me if this is a complicated problem or not.

Ralph Strauch wrote:I just updated to 1.1.0.25 and did a backup. The activity window is hung at "Stopping" and the log indicates a command failure and incomplete capture.

It's an interesting problem. The failure is a duplicate entry in the names index. It's relatively harmless, it just happened to trip an internal consistency check in the beta which in turn caused the capture to fail.

The real question is how the duplicate name got there and if it's a legitimate problem or just a side effect of some earlier bug.

If you've got the time, I'd love it if you could create a dump of your archive and send that to me. Open the archive and choose Archive > Dump.... Check the File Packages and Directory Packages options under Data (no need to include the details), and uncheck everything else in the panel. It will take awhile to run, during which the QRecall application will be completely unresponsive. So expect a spinning beach ball for a couple of hours. You can then compress the resulting report file and send that to me.

I've opened the archive twice and it doesn't sow the current backup at all. Each time I open it, creates a log entry that the "Archive contains auto-repair information.

The magic of auto-repair information. If the archive contains an incomplete or failed action, the auto-repair information makes it possible to treat the archive as if the incomplete capture never happened. If you start another capture, merge, or compact action the auto-repair information is used to first roll the archive back to it's previous (presumably pristine) state before the action begins.

I've sent the logs in from the app. You should have them now.

I got those, thanks.

Should I go back to the previous version to rerun the backup?

No, it won't really help. Ideally I'd like to diagnose this problem a little before proceeding, but ultimately I think the problem is in the names index file which isn't critical. A reindex or repair will probably fix it, but I'd still like to know a little more about what's going on before we try that.

To begin with, send a diagnostic report (Help > Send Report...). This will tell me a lot more about what is/was going on.

How is the USB drive formatted (HFS+, MSDOS, ...)?

Charles Watts-Jones wrote:QRecall is scheduled to run at night when no-one is logged in and, using Cocktail, I've set my external disk(s) up to mount without user login.

You might not need Cocktail. Code was added to QRecall to automatically mount directly connected hard drives when logged out.

It would be good if QRecall could survive disconnection/reconnection of an external drive.

In principle, it already does. However there may be circumstances beyond its control.

Unmounting a volume is an orderly process which QRecall deals with regularly. If the volume was being accessed, the operating system will return an error and QRecall will deal with that error as best it can.

However, abnormal disconnections are not orderly and there are cases that can lock up the drivers or kernel. In this situation, any application (QRecall included) is powerless to do anything about the problem because the application isn't executing anymore. Until the drivers or kernel are "unstuck" nothing short of a restart will fix the problem.

in my case I suspect an intermittent problem somewhere in the FireWire 800 'chain' as it has never happened with a FireWire 400 drive.

It may be the Firewire interface on the drive. I have encountered several external drives that exhibit bad/poor mounting behaviour. One customer has a FW400 external that disconnects every time the computer goes to sleep. The drive has to be powered off and back on again before it will reappear.

As always, I'd love to see log files and any crash reports (Help > Send Report...).

That's fascinating. If you asked me yesterday if I thought this was possible, I would have said no.

Bruce Giles wrote:Why does it happen?

An action document's reference to its archive is stored in a standard Mac OS alias record (the same data structure used when you create an alias file). An alias records volume identification information along with the name, original path, and file identifier of the original object. It then uses these bits of information, in various combinations, in an attempt to locate the original item.

I'm guessing that when I duplicated the drive in Disk Utility, it probably duplicated some hidden volume ID number as well, which wasn't changed when I renamed one of the drives.

That would be my guess too. It would be interesting to see if the UUIDs of the volumes are the same. You can see the UUID of the volume using the 'diskutil info <device>' command from the terminal. If the volumes do have the same UUID, then for all intent and purposes the system will assume that these are the same volume.

And QRecall probably uses that volume ID number instead of the volume name to connect a script with a particular archive.

QRecall just uses an alias record. The alias does all of the work.

So, is there a downside to doing this? It seems to be working so far...

Beyond being rather odd, there's little downside from QRecall's perspective. The alias will resolve to one archive or the other. QRecall doesn't care as long as it finds an archive.

I suppose there's some potential for confusion elsewhere. Any alias that refers to recently opened documents, favorites, preferences, and so on could all spontaneously refer to a different document when you mount the other external volume.

If this ever becomes a problem, I suspect that formatting the drive then duplicating it using something like QRecall, ditto, or Carbon Copy Cloner (which just uses ditto) would result in volumes with different identifiers.

Thanks for the feedback.

I'll look into some the anomalies you encounter. One thing on my to-do list is to determine if a newly restored system volume must be "blessed" first. This happens automatically when you choose a new startup volume from the System Preferences, but will not happen if you just restore and restart.

As for the icons, wiping a volume and copying all of the files back will break some aliases; not all aliases, but inevitably it will break some. This will occur no matter how you copied the files back as it reassigns the unique ID associated with every file.

ubrgeek,

One of the Apple network engineers thinks that the problem might be protocol interop issue. Would it be possible to capture a packet trace between the two machines during a capture? (I would suggest preforming a very small capture on a new archive, or else the trace will be huge.)

Interesting suggestions.

I do plan to add some scripting support to QRecall in the not-too-distant future. I think generalized scripting support would allow you to quickly implement these kinds of solutions — and many more I haven't even thought of.

ubrgeek wrote:Also, what is QRecallMonitor?

QRecallMonitor is a background (dockless) application who's primary purpose is to present the floating QRecall Activity window that shows the progress of running actions.

I've killed the process multiple times but it keeps respawning.

QRecallMonitor is installed as a launchd user agent. If you kill it, launchd just starts it again.

Is there a way to shut it down?

Not really, except by uninstalling QRecall or logging out.

I'm not sure if it's tied to the scheduler, but I don't have a desire to monitor du changes or schedule an automatic backup, etc.

It isn't tied to the scheduler, per se. It displays the status of the scheduler, scheduled actions, and the progress of independent actions started by the application. It also performs a number of useful tasks while you are logged in. Among other things, it monitors disk mount/unmount events and maintains the capture history information used by the QRecall contextual pop-up menu.

It will most likely be a problem with the next release, as a number of new features depend on FSCopyObjectSync.

However, there are potentially a number of solutions. Let me first investigate why FSCopyObjectSync is a problem on Samba shares and then look for a workaround.

Thanks for sending me your log files.

The problem is a curious one. During the process of duplicating files inside the archive, QRecall encounters error -54, which is a generic "permissions error."

The oddity is this: at the point where the error occurs, QRecall has already created an written a number of other files successfully, so to suddenly get a "permissions error" seems inconsistent. Then again, it might be a peculiarity of the FSCopyObjectSync function (which is the call that's failing).

Here are two things to try that might help us narrow the problem.

1) Try NOT pre-authorizing QRecall to run with administrative privileges. It's possible that Samba or FSCopyObjectSync is becoming confused when the processes switches UIDs.

2) Try the release version of QRecall (version 1.0.1). Version 1.0 doesn't use the FSCopyObjectSync function. To install the release version (or any earlier version), first uninstall the current version by holding down the Shift+Option keys and choosing QRecall > Quit and Uninstall. Replace it with the older version and start it up again.