Charles Watts-Jones wrote:Have followed instructions. All seems fine now.

That's a huge relief.

One very minor point, the Activity Monitor tells me that the next run is 'today' quoting a time that has already passed. Ideally it should say 'tomorrow' in this situation.

It's a known bug in the monitor. In some circumstances it's not updating its display when the schedule changes.

Steven M. Alper wrote:Forgive the obscure YES reference.

I'll have to forgive you, because I don't know the reference.

Verifies are hanging up at the last moment, apparently. I've got one working on a 92 gig quanta. At 33 hours I clicked the X button (no choices appeared). The X button is now greyed out at 42:09:53.

Two questions:

Does it happen consistently?

What version are you running? I made a recent change that would that might affect this. The change would have appeared in 1.0.0(49).

3 processes are waiting. (At 47 hours it'll be 4 processes.)

If it's what I suspect, you're going to have to kill -9 the action process. Either use the Activity Monitor or use the 'kill -9 <pid>' command. (A regular 'kill <pid>' is the same as a cancel, which you've already done.) A 'ps -auxww | fgrep QRecall' command will give you a clue as to which process started first. That's the one you want to kill.

Since this is a verify, there's no possibility of damaging the archive. The other actions will take off as soon as the first one dies.

QRecall 1.0.0(51) is available for download.

Choose QRecall > Check for Update... to update the application. After updating and reauthorizing, you should restart your system.

A late issue with the new scheduler has required a change in how the scheduler tracks volume mount/unmount events. These events are used to run actions that are triggered when a volume is mounted.

The new scheduler now starts a second QRecallScheduler process. This process listens for volume events while the user is logged in. When the user logs out, this process stops.

Note that OS X unmounts all ejectable volumes when a user logs out and mounts them again when the user logs back in. While logged out, volumes are not mounted -- even if they are mounted by another user. If you have actions that are run when a volume mounts, those actions will not run while you are logged out.

After upgrading to 1.0.0(51), it is highly recommended that you restart your system. There are security issues with replacing a running daemon (which will be ironed out in a future version). Restarting allows the scheduler to be started with the correct execution permissions.

A workaround for the volume mount/unmount notification problem has been worked out and is being tested. The solution is actually more robust and consistent than the previous version.

1.0.0(50) is on the alpha feed already. Expect to see it on the beta feed by Saturday.

This is why I hate making changes like this at the last minute.

Installing the Scheduler as a deamon has created a new problem: A race condtion during startup. The framework that the scheduler uses to detect volume mount/unmount events may, or may not, have finished initializing when the scheduler starts. If it hasn't, the scheduler crashes and starts again. This is why the logs are filled with broken socket errors.

I'm working on a solution to this, and a couple of related problems. Stay tuned. A new version should be available very soon.

QRecall 1.0.0(49) changes how the background scheduler process (daemon) is installed and run.

In prior versions, the scheduler was starting using a cron job. Starting with version 1.0.0(49), the scheduler is installed as a launchd daemon (in /Library/LaunchDaemons).

This should resolve a number of problem that people have been experiencing with Mac OS 10.4.10 and 10.5. Specifically, the scheduler process was being unceremoniously killed by the operating system when the user logs out or restarts. This was causing a raft of problems, ranging from messages about broken communications pipes, not running actions when they were scheduled to run, and leaving actions stuck indefinitely "waiting."

As a launchd daemon, the scheduler should now be running all of the time and doesn't have to be periodically restarted. This means less overhead, more predictable execution of scheduled actions, and QRecall won't be affected by customized installations of cron.

The first time you launch QRecall and it detects saved actions, you save an action, or you try to schedule or run an action interactively, it will prompt you to install the scheduler. You may be required to provide the name and password of an administrative user.

So you might be asking why the scheduler hasn't always been a launchd daemon? The reason is that this change breaks a big promise in QRecall: Namely, that all QRecall features are available to non-administative users, making QRecall usable in a lab or shared computer environment. I felt very strongly about this promise, but fighting Apple and their ever-changing treatment of background processes, cron, security, and kernel namespaces has made this impossible.

The interface for installing (and uninstalling) the scheduler will get some refinement in upcoming releases. In the mean time, please provide any feedback you have about the new scheduler installation process or any problems with the scheduler.

I wonder if this explains the problem I've been having on my sever.

Very likely.

Version 1.0.0(49) should resolve this problem. It's finished and available on the alpha release feed. It's been undergoing testing here for the past two days. If all goes well, I'll release it to the beta feed tomorrow.

Stephen Murphy wrote:Right now one big difference for me is that Time Machine can only backup to an external disk -- Apple pulled the Airport Disk functionality right before release.

That surprised me too. I have gotten no clear answer why Apple pulled the network volume support for Time Machine at the last minute. I can only guess that it was a performance issue.

On my laptop, I don't want to have to have an external drive plugged in all the time, and Qrecall works just fine with my Airport Disk.

I agree. If I couldn't back up my two laptops via Airport, I probably wouldn't be using QRecall either.

Ralph Strauch wrote:Time Machine appears to have a "prettier" and more transparent UI. The ability to go back and see old versions with QuickLook looks nice.

Having the recall GUI built into the operating system is a definite plus for Time Machine. Sadly, not an option available to third-party developers.

I think Time Machine backs up changed files rather than changed sectors, so it's archive will grow much more quickly than QRecall's. QRecall, OTOH, has a "geekier" UI requiring a bit more computer savy, but will use much less space for its archive or be able to save more layers in the same space.

Also correct. Time Machine, like most incremental backup solutions, copies entire files whenever they change. So small changes to large files will require considerably more storage.

Is a good summary of the differences, or is there anything important that I'm missing here?

The biggest differences today are efficiency (which you've already commented on) and control. Time Machine has one, fixed, backup schedule. QRecall gives you almost unlimited control on what gets captured, when, and how long it's saved.

My long term goal is to capitalize on QRecall's flexibility and control, so that it will eventually become "Time Machine Pro."

The space difference is a biggie, and this week when people are installing Leopard and exploring Time Machine would be a good time to promote that heavily. In the MacIntouch reader report on Leopard, http://www.macintouch.com/readerreports/leopard/ a number of people are expressing concern about Time Machine's archive growing rapidly because of small changes to large files. They'd likely be good candidates for QRecall right now. I'll post something about it if you'd like me to, but it might be better if you did it yourself.

I find that this sort of advice is better from actual users. When I post, it sounds self-serving -- which, of course, it is.

Ralph Strauch wrote:Why are two different keys needed?

When you reuse a single key on two systems, QRecall treats both computers as the same source. So from QRecall's perspective, you are capturing two volumes on the same computer rather than the single volume of two different computers.

The second reason is economic. Using QRecall's ability to combine duplicate data (like the OS) from two diferent systems is a significant advantage that QRecall has over almost all other backup systems available today. Using two identity keys let's me get paid for that work.

Related question? should it be possible to have a firewire drive mounted on both computers at the same time?

Not directly, no. A directly connected Firewire drive can only be used by a single computer at a time.

To share a volume with two or more systems you need to share it (there has to be some intermediate agent that arbitrates requests between the multiple systems). You could, for example, connect the drive to one computer, turn on Personal File Sharing, then mount the same volume on the second computer as a network volume. The system directly connected to the drive will arbitrate acces to the drive.

Frederic Thomas wrote:Did you get the logs? I'm just asking since I did not get a reply from you and it was a 5.x MBytes email...

Yes, I got the logs. I just haven't had a chance to look them over yet.

Also I am trying capturing something from OS X now, the volume that was giving us trouble.

Keep us posted...

Frederic Thomas wrote:My problem is (a) at some point I really need a working system and (b) disk space becomes a problem running multiple systems in parallel.

So I had to use the backup disk space for a working backup with Retrospect and had to delete the old archive: not easy to move around 250GB...

Not a problem. I understand completely.

Kept all the log files, sending them now.

Very much appreciated.

I am not sure I understood what test you'd like me to perform: OS X Server stuff on a OS X server only archive ? (even a local one?)

If the working theory is correct, that issues that occur when running OS X server are causing the archive corruption, then it should occur if captured to its own archive. So the test would be to set up the server to capture to an archive and see if the problem reoccurs.

But if you don't have the time or space to do that, don't worry about it. I still need to fix the missing icon resource problem and do some more investigation.

I've found out what the problem is.

A recent change to OS X now kills (SIGKILL -- essentially a force quit) any process belonging to the user when they log out. Worse, it kills any background process that tries to start up again.

This change makes it impossible for the scheduler to run while logged out.

I hope to have a solution soon.

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.