Thanks for the progress report.

I suspect the problem is a file pre-allocation bug that existed in Tiger. The bug was reported and Apple fixed it in Leopard. However, the Airport Extreme is probably using a code base that predates Leopard and thus still has the bug.

QRecall used a workaround when running under Tiger that was recently disabled when running under Leopard. When the file-preallocation is being handled by the file server (the AirPort Extreme) rather than the client OS, the problem reappears.

In 1.1(9) the solution was to go back to using the workaround for Tiger even when running Leopard.

Unless you re-encounter the problem, I'll roll this change into the next release of QRecall.

This indicates a mixed installation of old and new components.

Start QRecall and uninstall it (hold down the Option and Shift keys and choose QRecall > Quit and Uninstall).

Start it again. Open the QRecall > Preferences and reauthorize.

If that still doesn't fix the problem, download a fresh copy of QRecall, uninstall the old one (using Quit and Uninstall), replace the old QRecall with the fresh copy, then launch the new one and reauthorize.

Let me know if that fixes the problem.

Glenn,

Joe,

I have a theory about what the problem is. Try this and let me know what the results are.

Try this version: QRecall 1.1(9) beta

Download the disk image and open it.
Locate your existing QRecall application and drag it to the Trash.
Copy the new version to your Applications folder and launch it.

Alexandra Morgan wrote:How long can this take, after a merge action in which no layer were found to merge?

How long it will take to locate the unused space in an archive depends on a host of factors too complex to give any simple answer.

The fact the QRecall went looking for free space after a merge action that didn't actually merge anything sounds like a bug that I'll look into. It won't cause any problems, but is clearly unnecessary.

If your network is rather slow and your archive contains a lot of files (the primary factor in now long the free space collection takes), you may want to schedule your merge actions so they happen only occasionally (like once a week). This will minimize the amount of time reclaiming free space.

Send me your log files (you can find them in ~/Library/Logs/QRecall).

Also tell me a little bit more about the remote volume and the archive: How big is the volume, how much free space remains on the volume, and how large is the archive.

Joe,

Thanks for the log file and crash reports. The problem was caused by a bug that incorrectly handled the situation where a volume does not support Leopard's directory change notifications.

Try this version: QRecall 1.1(8) beta

Download the disk image and open it.
Locate your existing QRecall application and drag it to the Trash.
Copy the new version to your Applications folder and launch it.

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.