I finally had some time a few days ago, so I downloaded b12 and started using it. I just updated to b13 a few minutes ago. Here are my comments so far:

When capturing, the progress bar in the activity window goes to full (100%) immediately at the start of the capture, and then it never changes after that. I have this same problem in the current release version of QRecall also. (Just as I was getting ready to post this message, an action started another capture, and this time the progress bar seems to be working correctly. Is that something you fixed in b13, or have I got some kind of inconsistent thing going on here?)

My old backup drive was getting a bit flaky, so I bought a new external drive, and set up new archives for beta testing. I have not yet tried to convert my old archives. When i opened the new archive window for the first time after the first capture, it opened in icon mode. There was a blank icon with my name under it. I had to double-click the blank area to open up a new view showing the hard drive, and then I got an icon on the drive. The lack of an icon to go with my name was disconcerting -- at first I didn't even see it and thought the archive action hadn't worked. Did you intend to have some kind of icon there, or was it supposed to be blank?

Will the capture assistant be updated to support the new event conditions? I like the new conditions. I'm testing the one that waits to back up my virtual machine folder until after VMware Fusion quits, and so far, it seems to be working.

Feature request: Two-column sorts of the Actions window. I'd really like to see actions sorted first by the Archive column, and then by either the Next or the Schedule column.

In the release notes, "scraping" should be spelled as "scrapping", with two "p"s. Mentioned so you can get it right in the help files.

That's all I've got for now.

-- Bruce

I understand. I'll keep an eye on the forum and wait for the official announcement.

James Bucanek wrote:

Bruce Giles wrote:If the event has already passed, I would prefer that QRecall just forget about it and wait for the next scheduled event. I could swear it used to work that way. Did I mis-remember, or did I do something wrong when setting up my scheduled tasks?

Bruce, you aren't mis-remembering. As one of QRecall's oldest customers, you probably remember when QRecall didn't run actions while the computer was asleep or shutdown. This generated a lot of complaints and the scheduler was modified to find, and immediately run, actions who's next scheduled time was now in the past.

Yes, but I thought I remember it behaving that way recently, before I installed the new drive.

Solution #1: If your system doesn't auto log into your account, you could set the scheduler to run as a daemon and add the "Ignore while user is logged out" option to your capture actions. The computer will start up, the scheduler will start, the actions will try to run, but won't because you're not logged in yet.

Ah! I think that was probably what I was doing before. I just checked, and the "Start and run actions while logged out" was turned off. I'm sure it used to be on. I vaguely remember turning if off several weeks ago because I never leave that computer in an "on, but logged out" state, so I was figuring it wasn't necessary. I've just turned it back on again, and I think that will probably solve my problem. The account is indeed set to not automatically log in. I'll make sure to add that action.

Solution #2: Add the "ignore if no archive" to your schedule. When you turn on your Mac, don't turn on your external drive. The scheduler will try to run the tardy actions, but see that there's no external drive and skip them. Once you're logged in, turn on your external drive and captures will begin normally.

I'll add that action too. Some days I'm only on that computer for a few minutes, and if so, I usually don't need to run a backup and usually don't turn on the external drive.

When the backups start running just after login, I usually cancel them from the monitor window. However, if I do that, and then reboot later, the backups attempt to run once again after login, even if another scheduled event hasn't yet occurred. Any ideas?

That's hard to say. If four hours have passed, or you just logged out and four hours have past, I would expect the capture with the interval schedule to run immediately when you log back in. If the daily action is running immediately after being canceled, then something might be wrong. Start by sending a diagnostic report.

It happened today when I installed some software updates immediately after logging in, and then immediately rebooted. I didn't think any scheduled events should have triggered during that time, but I might have been wrong. I'll try to pay more attention, and if it's still happening, I'll send a report.

Finally, I'm considering adding an "ignore if asleep or shutdown" condition to actions in QRecall 2.0 so you can simulate the original behavior.

I almost suggested that, but was thinking maybe you already had and I just wasn't looking in the right place to find it. You can add me as a vote for that action.

So I saw you hint in another message that another beta cycle might be coming up soon. Care to comment any further on that yet?

Thanks, James!

I recently installed a new SSD in an old iMac, and took the opportunity to wipe out all my old actions, which were no longer doing what I wanted, and start fresh with a new set. But I think I've missed something somewhere...

This iMac doesn't run every day -- more like one or two days a week. The rest of the time it's powered off. I have an archive action for the entire hard drive scheduled for 12:00 PM every day, and an interval action that backs up the home folder every 4 hours. The archive is on an external drive that I usually turn on when I start up the Mac, but not always (depending on how long I intend to run the computer).

The problem is that when I start the Mac after it's been off for a day or more, as soon as I log in, QRecall immediately attempts to run both the both the full backup and the home folder backup. I presume this is because some of the scheduled events occurred during the period that the Mac was off, and now QRecall is trying to catch up for the missed events. This isn't what I want it to do, however. If the event has already passed, I would prefer that QRecall just forget about it and wait for the next scheduled event. I could swear it used to work that way. Did I mis-remember, or did I do something wrong when setting up my scheduled tasks? I thought that maybe "ignore while user is logged out", or "ignore if no archive" would do the trick, but it didn't.

When the backups start running just after login, I usually cancel them from the monitor window. However, if I do that, and then reboot later, the backups attempt to run once again after login, even if another scheduled event hasn't yet occurred. Any ideas?

James Bucanek wrote:Much of this work has already been done, but a lot still remains. I'm currently writing two books for Apress, which is consuming most of my time, but I assure you that work on QRecall continues.

That's great to hear about all the upcoming changes and improvements in QRecall! Just out of curiosity, can you san anything about the two books you're working on?

-- Bruce

Sounds great -- thanks!

Hi James,

I have an action to automatically compact my QRecall archive, which is located on an external USB hard drive. It's been running for about 30 minutes as I write this. For most of that time, the progress bar in the Activity Window has been all the way at 100%, and the message underneath says "Locating unused space, moved Zero KB, recovered Zero KB"

I assume it's doing something, because the drive is a little noisy, so I can hear the heads moving, but from looking at the Activity Window, it would be easy to believe that it was frozen. There's just nothing going on there, except for the timer counting up.

Oh, wait -- it just finished. Total time about 36 minutes.

Anyway, I think you need to do something better with the progress bar in that situation. It's really confusing (or misleading) when it goes all the way to 100% and then just sits there for tens of minutes. If the "locating unused space" step is not something you can quantify in order to show progress with the bar, then how about switching to an indeterminate ("barber pole") type progress bar instead?

-- Bruce

Sorry, the problem turned out to be at my end, not yours. I'll mention the details here just in case anyone else runs into the same problem.

We're using a Sophos (formerly Astaro) Security Gateway, that uses Snort rules for intrusion protection. For some reason, and I don't understand why, at 3.6 megabytes into the download, Snort was reporting this error:

2012:12:14-17:09:49 fw-1 snort[5443]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="drop" reason="WEB-CLIENT OpenOffice TIFF file in big endian format parsing integer overflow attempt" group="310" srcip="69.50.200.162" dstip="192.168.31.11" proto="6" srcport="80" dstport="51340" sid="15976" class="Attempted User Privilege Gain" priority="1" generator="3" msgid="0"

Clearly, your update is not an OpenOffice TIFF file, so this was some sort of false positive. Anyway, I disabled rule # 15976 in the intrusion protection settings in the firewall, tried the download again, and got the update with no problems. I also tried the same thing at the other location, which also had an Astaro/Sophos firewall, and that solved the problem there as well.

-- Bruce

Hi James,

QRecall notified me that version 1.2.2 was available, so I tried to update, but it fails. Actually, it's failed repeatedly on two different computers, at two different times, from two different locations. The symptoms are that the download starts, and proceeds rapidly, until it gets to 3.6 out of 11.5 MB. And there it stops. The progress bar stops moving and nothing else happens for about a minute, then I get an "Update Error!" alert that suggests to try again later. Any idea what's wrong?

-- Bruce

Sounds like the perfect solution. Thanks!

I ran into an interesting QRecall problem today.

Background: A couple of weeks ago, I replaced the stock hard drive in my Mac Book Pro with an SSD hard drive. I was prepared to use QRecall to transfer all my files from the hard drive to the SSD drive, but I tried Migration Assistant first, and that worked just fine. And QRecall seemed to be working just fine on the new drive as well. I do notice that it seems to be significantly faster now, even though the backup drive is still a non-SSD hard drive.

So, I thought everything was good until this morning, when I happened to open Console. I found hundreds (thousands?) of entries like this:

Feb 3 12:05:25 BruceMacBookPro com.apple.launchd[1] (com.apple.launchd.peruser.501[223]): getpwuid("501") failed
Feb 3 12:05:35 BruceMacBookPro com.apple.launchd[1] (com.apple.launchd.peruser.501[224]): getpwuid("501") failed
Feb 3 12:05:45 BruceMacBookPro com.apple.launchd[1] (com.apple.launchd.peruser.501[227]): getpwuid("501") failed

As you can see, the same entry was repeating every 10 seconds.

After spending a little time with Google, and the command line interface in Terminal, I figured out the problem. On the old hard drive, my UserID was 501. On the new SSD drive, after Migration Assistant transferred everything over, my new UserID was 504. There is no UID 501 on the SSD drive.

The problem was in /Library/LaunchDaemons/com.qrecall.scheduler.kickstart.plist. I examined the file in BBEdit, and found some lines like this:

<key>Program</key>
<string>/Library/Application Support/QRecall/QRecallKickStart</string>
<key>ProgramArguments</key>
<array>
<string>501</string>
<string>504</string>
</array>

I deleted the "<string>501</string>" line, and saved the changes (making sure the owner was still root/wheel). I rebooted, and the problem had disappeared.

So, if I'm interpreting this correctly, the launch daemon was attempting to QRecallKickStart as both UID 501 and 504. Since UID 504 existed, QRecall was working correctly, but since UID 501 no longer existed, it was also generating tons of error messages.

I don't know how the 504 UID got added to the plist file, but assuming QRecall did it, then it seems like it also needs to look at any other UIDs in the file and delete any that are no longer valid.

-- Bruce

I happened to be sitting in front of my MacBook Pro this morning when one of the scheduled actions ran. I saw, for the first time, a notice in the activity window that a new version was available. Since QRecall was in the middle of a merge operation when I saw it, I figured it was best to wait until the scheduled operations had completed before I did the upgrade. However, as soon as the scheduled operations completed, the activity window disappeared, along with the update notice. Seems like that notice ought to hang around until acknowledged. Otherwise, those who schedule their actions for the middle of the night might never see the update notice unless they happen to launch QRecall manually.

-- Bruce

Does QRecall check for updates when the application isn't running? Would it be possible to post an notification of updates in the Activity Monitor window (possibly as a preference, in case some people don't want that)? I don't launch QRecall very often, because it mostly just does what it does, without needing any interaction from me. So when I *do* launch it, I often discover that one or more beta updates have happened that I wasn't aware of.

Also, are you documenting the new features yet, and how to use them, anywhere other than in the update notification window? Recent versions have added a lot of new features, and I'm sure I'm not using them all (which means not testing them all) simply because I don't remember them all, or don't remember the details on how to use them. I know you've done a bunch of things related to the "Show Deleted Items" command, but searching the Help window for "Show Deleted Items" doesn't turn up any of them.

-- Bruce

Does QRecall (either the current release or the beta) require Spotlight on the backup volume? Or to put it another way, is it OK to put the backup disk into the Privacy section in Spotlight's settings?

-- Bruce

James Bucanek wrote:

Ralph Strauch wrote:Will I encounter any problems if I name both drives and archives identically, and use the same Action to backup to whichever drive happens to be connected?

Most likely, yes. Mac OS X is pretty smart about not being fooled by different volumes and/or files with the same name. It will undoubtedly recognize that the volumes are different and will probably refuse to use one of them outright.

I have an interesting solution to the problem. Unfortunately, I can't tell you exactly how I did it -- it was a fortunate accident. But it might be useful to someone...

I have two external FW800 drives I use as rotating backups. They have different names -- "Xserve Backup A" and "Xserve Backup B". Each drive, however, has an archive file with the same name -- "Xserve Backup A.quanta". Yes, you read it correctly. Drive "Xserve Backup B" has an archive file named "Xserve Backup A.quanta".

The interesting part is that I have only one set of actions, which "automagically" modify themselves to work with whichever backup drive is mounted. I don't know how they do that. When drive "Xserve Backup A" is mounted, my actions all point to:

/Volumes/Xserve Backup A/QRecall Backups/Xserve Backup A.quanta

When drive "Xserve Backup B" is mounted, my actions all point to:

/Volumes/Xserve Backup B/QRecall Backups/Xserve Backup A.quanta

If I edit an action, I can actually see the wording in the archive location changes, depending which drive is mounted.

I *think* what happened was that I originally created one backup drive, got it all configured in QRecall, then used SuperDuper to clone it to a second drive. Then I changed the name of the second drive, but didn't change anything else. Anyway, it's worked perfectly that way for several years. I don't, however, ever mount both backup drives on the Mac at the same time. Seems like that might be asking for trouble.

-- Bruce