Please send me your log files (~/Library/Logs/QRecall) and any crash report files that begin with QRecall (~/Library/Logs/CrashReporter or /Library/Logs/CrashReporter).

You can send them directly to me or upload them to the forum.

Alexandra Morgan wrote:if the user logs out while the action is running, will the action continue to run?

It depends. If the action was started by the scheduler, either by scheduling it to run automatically at a particular time or by using the Run Immediately or Run At commands, AND the scheduler is authorized to run while you are logged out, then the action should continue to run and the networked volume should stay connected.

However, if you start an action interactively or if your scheduler is NOT authorized to run when logged out (QRecall > Preferences > Authorization > Start and run actions while logged out), then logging out will stop the action.

It has to do with the "scope" of the process. Programs that you start yourself belong to your log-in session. When you log out, Mac OS X terminates all processes started by your log-in session.

To accomplish what you want using QRecall, you would create an archive and schedule it to capture your database folder every day at 11:45 PM. (The Capture Assistant will walk you through the setup.) At 11:45 PM tonight QRecall will capture the folder, adding a new layer in the archive. This new layer (dated 6/16/2008 11:45 PM) will contains the files in that folder as they existed at the moment they were captured.

You can later browse the layers in the archive and recall the folder as it existed at a previous date.

QRecall is particularly efficient when dealing with database and multimedia files; It only captures the data that actually changed in each file rather than making a copy of the entire database every day.

The log entries are very interesting. QRecall uses the BSD database of users to determine the home folder of every user defined on the system. If your computer is connected to a network with a networked Directory Services server, QRecall might be plowing through every user defined on the network.

Anyway, the most straightforward approach to figuring out what it's doing would be to take a sample of the application the next time it's in a stupor. Launch Activity Monitor, select the QRecallHelper process, and click Sample Process (usually in the toolbar, but View > Sample Process or Command+Option+S works too). Save that and send it to me.

Charles Watts-Jones wrote:No in that I didn't trash the current version …, I just tried to instal over it which is my usual practice with upgrades.

That's where you ran into trouble.

QRecall installs several components and a background processes, some of which are contained in the application bundle. This means that the application bundle contains resource files which are always in use. Attempting to replace the existing application with the new one fails, because the Finder refuses to delete the files that are active. You end up with a half-deleted/half-installed version of QRecall.

Normally, you'll never encounter this. The initial installation is immune, and upgrades are handled automatically by a process that first downloads the new version, sets the old one aside, starts the new version which uninstalls the resources open in the old one, and then safely removes the old version.

Manually switching from a release version to a new beta is where some care must be taken.

(in my defense I'd add that I had never read that page before)

That's because, until this second beta, no one — except maybe myself and a few testers — has ever needed to install a new beta over a released version.

Charles Watts-Jones wrote:I have QRecallMonitor running. The beta complains about this and won't instal. And the instal then complains about 'Resources'. I can't find that in Activity Monitor, is it the same as 'QRecallScheduler'? If so, should I have Activity Monitor kill them both?

Please send me your log file.

Out of curiosity, did you follow the installation procedure at http://www.qrecall.com/download/?

By the way Bookdog ships with a Terminal script that does the necessary before updating. Something QRecall might have too?

QRecall automatically removes and replaces all old components with the new ones. No install or uninstall scripts are required.

If you would like to uninstall QRecall before installing a different version, choose QRecall > Uninstall and Quit (Command+Option+Shift+Q) in the old version, then install and run the new version.

Welcome intrepid beta testers,

The beta version of QRecall 1.1 is now available for download and testing.

Please review the release notes before installing version 1.1 (there are some features that will make your archives incompatible with QRecall version 1.0).

If you already have a permanent identity key, you may continue using it with the beta. If you have not purchased a key, or need an additional key, you may create an account and request a free beta identity key. A beta identity key will only work with this specific version of QRecall and will expire at the end of the beta test period.

As always, Dawn to Dusk Software welcomes your feedback, bug reports, and suggestions.

Michelle Parker wrote:The thrashing is the problem though, how long should I wait for the memory to be freed, because I have been waiting 15 mins or longer?

It's really hard to say without knowing any more details. I admit that 15 minutes sounds like a long time, but it's not unheard of.

I would like to add a condition to not start if the computer is being used, but I can't logout because everything is still open.

No such condition exists at this time. I'll add it to the request list.

So, which is better 'pause' or 'suspend'?
Which one can handle a system restart in the middle?

Pause simply suspends the action, but leaves it running. Stop and Reschedule actually stops the action, closes the archive, and then reschedules it to start again at a later time. You can log out or restart anytime after it stops. The advantage of Pause is that it's almost immediate, where Stop and Reschedule will take longer to finish up.

Michelle,

It sounds like you're doing the right thing. If QRecall is too much of a burden on your system, pausing or rescheduling the action is exactly what you'd want to do.

QRecall can never cause your computer to "stop dead." What I suspect is happening is that QRecall and other applications are competing for memory. This results in a situation called "thrashing" where the system spends most of its time swapping memory to and from the virtual memory swap space rather than running code. This results in exactly what you describe: Applications just hang, spinning multi-colored cursors, unresponsive keyboard, changing windows takes forever, new applications don't seem to launch, and so on. This can persist for many minutes.

You can confirm this by starting and running an application that will monitor the system's virtual memory activity. My personal favorite is iPulse, but Activity Monitor or running the 'top' command in Terminal will work too. When your system become unresponsive, you want to watch the virtual memory paging activity. If you see the VM system constantly paging in and out (page in/out numbers going up up up), then your system is thrashing.

If the system is thrashing, you should still be able to pause or reschedule QRecall -- although it might take some patience. Eventually, the memory used by QRecall will get paged out, the memory used by your other applications will get paged back in. and your system should return to normal.

So either be patient or get some more RAM. Also make sure you have plenty of free disk space. The VM systems gets even less efficient if the free space on your startup drive is low.

There are also some other strategies for minimizing interference with your regular work, such as scheduling QRecall to run at night and adding schedule conditions so that it automatically stops before you normally start using the computer.

Roger Schriner wrote:When I run an action I see files that have not been modified and I would think they would have been backed up on the initial backup.
Is this correct?

That is correct.

However, QRecall will consider a file to be "changed," and subsequently recapture it, if anything about the file has changed. This includes entirely innocuous things like changes to its metadata, file permissions, and so on. In essence, if anything about a file that QRecall has previously captured appears to be different, the file is recaptured.

Also note that that the capture status display will show a folder being recaptured if it contains invisible or hidden items that might have changed. It's very common for the OS and Finder to modify invisible files within a folder or application. QRecall to display "Capturing Folder Whatever" while is examines those invisible files.

If you are really curious as to why QRecall is recapturing an item, set the QRLogCaptureDecisions option (see Advanced QRecall Settings) and preform another capture. You can then look in the log to see the (first) reason why QRecall decided recapture each item.

Remember to turn this option off when you're done, as it will create monstrous log files if left on.

Stuart Parker wrote:In the case of a Repair, with the 'Copy Recovered Content to New Archive' option set, what steps should be taken after it has finished? The repair had to be run because when the original archive was opened it would only give the repair option.
Should I delete the original archive and rename the recovered archive to the same name as the original archive?

If the repair was successful (and it sounds like it was), then yes; You can delete the original archive and replace it with the repaired one.

Does this type of repair only copy the good data, & if so, how can I determine what wasn't copied, or is this not determinable?

During the repair, QRecall will log what problems it encountered. It can't always determine exactly what is missing -- the nature of bad data is that it's bad. If there are no warnings about bad files or data in the log then most likely nothing was lost.

The other two repair options (Recover Lost Files and Recover Incomplete Files) can be used to recover file data that might have been lost due to damaged directory or layer information. But again, if the repair didn't log any warnings about damaged directories or layers then are aren't any orphaned files to recover.

bruce jacob wrote:my setup is an airport extreme network at home with a couple of laptops and a terabyte NAS drive with wireless access (the Iomega "storcenter" drive). QRecall shoves data over the net about 3x faster than Time Machine, which rocks, but every time I run it, I get a failed capture ... so I have yet to make a successful backup.

Bruce,

It looks like you're losing the connection with the NAS drive. This could be either a dropped wireless connection or the drive itself is going off-line. Given my recent experience with wireless, I'd guess the former. The key message in the log file was

2008-05-05 00:16:45.389 -0400 Capture failed
2008-05-05 00:16:45.389 -0400 A storage or disk error occurred while writing to the archive data. This could indicate a hard drive failure, or the drive or volume was disconnected. The archive is probably damaged.

This means that QRecall suddenly couldn't read or write to the archive.

What you might try is this: Perform the first, full, capture with the Iomega connected directly to the laptop then plug it back into the Airport Extreme then see how things go. This isn't a solution as much as just trying to avoid the problem. Once the initial capture is finished, subsequent captures will be much faster and the chance of losing the network during the capture is smaller.

I'm currently working on a version of QRecall that will tolerate the loss of a drive or network connection during a capture much more gracefully than the current version. I know I've been promising this version for a couple of months, but both personal and professional interruptions have delayed getting it into beta. Hopefully, I should have version 1.1 available as a beta by the end of May. So try doing the initial capture directly and look for a beta of QRecall in the near future.

Hold down the Option and Shift keys and select QRecall > Quit and Uninstall. This will disable and remove all of the application's active components.

To completely eradicate any trace of QRecall from your system, follow the instructions in Help > QRecall Help > Advanced > Uninstall QRecall > To Manually Uninstall QRecall.

Ah, that might be it.

The warning triangle indicates that a problem occurred when the action ran. The action's status will remain in the activity window indefinitely until you click on the warning button and dismiss the error.

David Stevens wrote:I had a series of actions set up to backup my whole laptop to an external drive attached to a Mac Mini on my Airport network.

For whatever reason, it never completed any of the actions, and so I decided to give up on that until I get a Time Capsule (which hopefully _will work!).

I can't think of any obvious reason why that shouldn't have worked. If you'd send me you log file(s) (~/Library/Logs/QRecall) I'd be interested in finding out exactly what went wrong.

So I deleted the actions in the QRecall window on my laptop (MacBookPro). But every morning I find the QRecall Activity monitor up on my laptop, with the deleted Compact and Merge actions shown (Stopping). How do I make these go away! And should I have removed the Actions in a different way?

No, removing the actions from the actions window should delete them.

The folder ~/Library/Preferences/QRecall/Actions contains your action documents. If you've deleted all of the actions the Actions window and you still see them in the Actions folder, then something's wrong. Again, your log file might contain some clues.

If you haven't restarted, you might try that and see if that fixes the problem. Let me know if it does, as this would indicate that the scheduler wasn't notified that the actions were deleted.