James Bucanek wrote:You can fix your problem by deleting the file /Library/LaunchDaemons/QRecallscheduler501.plist and then restarting.

Yep, that fixed it.

It would also be a good idea to go into your Accounts system preferences pane and check your login items. If you have a login item for QRecallMonitor, delete it too.

I didn't have anything from QRecall there.

Here's what happened:

You kept on using beta version 1.0.0(51), which I think expired sometime during the Reagan administration.

That's possible, I suppose. Normally, I only use this iBook one day a week at most, and I don't back it up every time I use it. I probably haven't actually run QRecall on that machine in a while. But when I ran it yesterday, it told me I needed to upgrade, so I did.

Around version 1.0.0(55), the names and locations of the scheduler's configuration files changed. Versions 1.0.0(55) through release candidate 2 included code that would look for these pre-(55) installations and delete them automatically.

But since you skipped directly from 1.0.0(51) right to the final release (which has no beta version clean-up code), you ended up with both the 1.0.0(51) and the 1.0 schedulers installed simultaneously.

That makes sense. Thanks for the explanation. Which leads to another question. For those of us who have been through multiple alphas and betas, would it be a good idea to start new archives with 1.0? Or are we OK with our older archives, as long as they verify?


-Bruce

/Library/LaunchAgents/:

com.hp.launchurlagent.plist
com.qrecall.scheduler.plist

/Library/LaunchDaemons/:

com.qrecall.scheduler.kickstart.plist
QRecallscheduler501.plist

~/Library/LaunchAgents/:

com.qrecall.monitor.plist

James,

We're running QRecall rc1 on our server now. The good news is it seems to be working fine. Backups are working, and the archives verify later. But I've noticed one odd thing.

In the "Identity Key" section of the preferences, it says "none" for both the owner and the key status. If I click the Enter Key button and re-enter the key, it seems to work and I'm told there's 14 days left before the key expires. But on quitting and restarting QRecall, we're back to "none" again. In spite of that, backups are working, and I'm not seeing any messages complaining about the lack of a key.

Is this a bug, or just something to do with getting into the final candidates?

-- Bruce

I have no idea when this stopped, but I just realized that the "hover effects" are no longer working in QRecall build 55 on my Intel iMac running Leopard 10.5.1. When I move the cursor over the bottom pane of the archive window, no highlights occur, and the associated timeline line doesn't go bold. Moving the cursor over items in the top pane no longer causes the associated items in the bottom pane to highlight either.

I'm sure they're turned on, because under the View menu, the first two items are "Hide Timelines" and "Hide Highlights". And I do see the timelines, they just don't react to cursor movement.

Other than this, everything else in QRecall appears to be working normally. Restarting QRecall and even rebooting the Mac haven't restored the hover effects.

Interestingly, they're still working on the copy of QRecall installed on our Intel Xserve. That's also build 55 and OS X Server 10.4.11.

-- Bruce

James Bucanek wrote:Very interesting. What's curious is that those messages are from the debug version of the malloc libraries, and as far as I know I didn't ship any versions of QRecall that use the debug malloc library. It might be possible that you have an environment variable set that enables this (this might even be standard on the server). It's worth investigating.

I wouldn't have the slightest idea how to investigate that, much less even set the environmental variable. I did, however, install the Xcode tools on the server. Might that have done something?

Regardless, the messages appear to be coming from the QRecall client. Since you suspect that this occurred in the last 48 hours, do you happen to remember what you might have been doing in the QRecall application lately? This would help me in trying to reproduce the problem.

In that period of time, it ran some actions that were created by the assistant. I modified them all to change from "hold" to "ignore" if the backup drive was not present. I changed the interval on the capture from once a day to once an hour, for a few hours, then back to once a day again. I probably opened the archive a few times to check that everything was working. And that's all I can think of.

I'm going to the server now to see if I can duplicate it. I'll report back shortly...

-- Bruce

I just happened to be looking through the console log on our server (which is currently running X Server 10.4.1) this morning, and found these entries:

QRecall(7950,0xa000d000) malloc: *** error for object 0xad25760: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug
QRecall(7950,0xa000d000) malloc: *** set a breakpoint in szone_error to debug

Since there's no dates, I'm not sure when this happened, but I think the console log is cleared at reboot, so it would have been in the last 48 hours. As far as I know, QRecall hasn't actually crashed. It seems to be working just fine.

-- Bruce

James Bucanek wrote:I've never used Amazon SSS, so I can't comment about that.

You might want to take a look at it. The "Security Now!" just devoted an entire episode to Amazon S3 and JungleDisk, which is a Mac-compatible front-end to S3. I don't know if that's what the original poster was using or not, but it gives you access to S3 that looks like any other mounted network volume.

I agree that unless you've got really really fast Internet uploading speeds (and note that most cable and DSL services cap your upload speed to a small fraction of your download speed) you won't want to back up anything large to S3, at least not frequently. But I can see where it would have its uses, especially if you have a few critical things you want to store off-site, and it might be nice to use QRecall for that.

I should add that I haven't tried S3 myself yet, but it's on my list of things to do.

I was moving our old server (Mac OS X Server 10.4.11) to a different place on our network, and as part of that, I ran the "changeip" command. Something went horribly wrong, and changeip crashed about halfway through the process, leaving our server settings a mess. Some things got changed, and others didn't and I wasn't exactly sure which was which.

I knew I had a good QRecall backup from 2:00 this morning, and there had been no significant changes since then (except for what I did with changeip). The problem was that I didn't know exactly which files changeip had changed, so I didn't know which ones to restore.

What I ended up doing was a complete volume restore, which worked perfectly. (I did boot from the bootable backup volume first, although I understand from the help files that QRecall could have done a live restore. I just figured it might be safer not to be running on the disk being restored.)

So the full volume restore worked, but it seemed a little like swatting flies with an atom bomb. Was there a better way to do this and just restore whatever files had been changed since the last capture? Or is that actually what the full volume restore did?

-- Bruce

James Bucanek wrote:That's so cool!

Seriously, I have no idea why this is happening. Sometimes you get the huge icons and sometimes you get the regular ones. The size seems to persist until you close and reopen the Quick Start window.

For a short while, I thought maybe it was somehow tied to icon view in the Finder, but that doesn't seem to be the case.

-- Bruce

I'm not sure if this is a bug, or intentional. In the QuickStart window of beta 53, the entries in the Open Recent pop-up menu are huge. This is under Leopard (10.5.1) on an Intel Mac. See the attached screen capture. The previous version of QRecall, running under 10.5.1 on a G4 iBook doesn't do this.

-- Bruce

James Bucanek wrote:QRecall 1.0.0(53) resolves this issue.

Confirmed. I removed the QRecall, Monitor, and Scheduler entries from my firewall list, then launched QRecall (after rebooting), and it didn't ask me about incoming connections at all.

QRecall launches *extremely* quickly now. In fact I use LaunchBar to launch it, and the QRecall QuickStart window appears before the LaunchBar "window" has even started to go away. Opening archives is much faster, too. I'm not sure if you did something in this version, or if it's been that way for a while and I'm just now noticing. (To be fair, I've been running it on an Intel Mac for only a couple of weeks, and most of that was automatic schedules, so I hadn't spent a lot of time actually launching QRecall or opening archives.)

-- Bruce

Bruce Giles wrote:I'll try to restart it sometime in the next day or two. I'll let you know if that clears up the problem.

It did. The errors are no longer occurring.

-- Bruce

James Bucanek wrote:Clearly, you've turn on the firewall.

Yep.

Leopard is confused.

I'm glad to know I wasn't the only one.

I have no idea why it thinks QRecall implements any network services. This version of QRecall doesn't creating any incoming TCP sockets.

The only network communications at the moment is via the Sparkle framework that checks for version updates. Sparkle works over HTTP (port 80) and doesn't require any incoming access.

Well, QRecall isn't the only one that Leopard seems to be confused about. I've been asked that question for a lot of apps that I'm nearly certain don't really need incoming access. I see that I have entries in there for QRecall, QRecallMonitor, and QRecallScheduler. But I also have things like Safari, Cyberduck, BBEdit, and RealPlayer. I'm fairly certain none of those require incoming connections.

So in the end, it doesn't matter if you answer Deny or Allow, QRecall should work just fine. I'm trying to find out why Leopard thinks QRecall accepts network connections and how to get it to stop asking silly questions.

Actually, after sending my first message on this subject, I got asked about QRecall.app several more times while I was setting up a schedule via the assistant. As a matter of fact, I just tried to launch QRecall again, and it asked me again, so this time I said "Deny" just to see what happened. It changed the firewall setting from "allow incoming connections" to "block incoming connections", but it's a mystery to me why it was no longer willing to accept the answer that was already there.

Anyway, as you said, QRecall seems to work just fine with either setting.

When you install and run QRecall for the first time under Leopard, it asks:

Do you want the application "QRecall.app" to accept incoming network connections?

If you click "Allow", then you get asked about installing the scheduler. After that, you get a second instance of the first dialog, asking if "QRecall.app" should be allowed to accept incoming network connections. After clicking "Allow" again, then you're asked:

"Do you want the application "QRecallMonitor.app" to accept incoming network connections? Clicking "Allow" on that one finally allows QRecall to finish launching.

I realize these are "one-time only" questions, and I know that responding "Allow" causes them to be added to the Leopard firewall list. But what I don't understand is if they really do need to be allowed.

I know QRecall needs to be able to make OUTGOING connections in order to check with the update server. And I'm assuming that if it initiates an outgoing connection, the firewall will allow the incoming reply. Or is that not correct? If it is correct, then under what circumstances would something from the outside need to initiate a connection with QRecall? And why do I get asked twice about "QRecall.app"?

-- Bruce

James Bucanek wrote:Has the system been restarted since you upgraded QRecall?

I don't recall for certain, but probably not. Since it's a server, and usually in use while I'm at the office, I rarely restart it. But it has several system software updates waiting to install, and probably won't be in use much this weekend, so I'll try to restart it sometime in the next day or two. I'll let you know if that clears up the problem.

-- Bruce