Hi James,

I was looking through my QRecall log today, for the first time in quite a while, and I noticed the following error message occurring once or sometimes twice a day:

Unable to connect with helper
cannot establish a connection with helper
Port: QRecallHelper.28be5bb1

The hex number in the third line is different every time. The time of day when the message occurs varies, but it's always at odd times not associated with anything on QRecall's schedule. It's been going on for months, but apparently it's not serious, as the next scheduled task always occurs on time and completes without error. Any idea what's happening here?

-- Bruce

Hi James,

Just wondering -- are there any known issues with QRecall and Mavericks? I haven't done the upgrade yet, but I'm doing a full backup now, in preparation for that.

-- Bruce

I see 1.1.3 is out -- I just downloaded it. My copy of Snow Leopard hasn't arrived yet, but since I'll have to support it, I expect to be an early adopter. Thanks!

James,

Are you allowed to talk about compatibility of QRecall with Snow Leopard yet? Does it work? Any problems?

James Bucanek wrote:Download QRTouchXAttrsXItems and try it again. This version should work on 10.4 and 10.5.

Yes, that worked. Thanks!

James Bucanek wrote:Note that QRecall 1.1 won't recapture an item just because it has extended attributes and the previously captured version doesn't. See the "Utility to recapture items with extended attributes" thread for details.

I just tried that, but the utility fails to run:

dyld: lazy symbol binding failed: Symbol not found: _realpath$DARWIN_EXTSN

  Referenced from: /Volumes/QRecall Extended Attribute Nudge Utility/./QRTouchXAttrItems

  Expected in /usr/liblibSystem.B.dylib



dyld: Symbol not found: _realpath$DARWIN_EXTSN

  Referenced from /Volumes/QRecall Extended Attribute Nudge Utility/./QRTouchXAttrItems

  Expected in /usr/liblibSystem.B.dylib



Trace/BPT trap

Note that this system is still running Tiger Server, not Leopard Server, if that makes a difference.

I hesitated posting this here, because I'm not at all sure it's QRecall's fault, but I'll never find out if I don't ask.

I'm running both QRecall and Time Machine. Why both? Well, I'm still running test versions of QRecall, and I like to have a backup plan for my backup plan, if you know what I mean.

Anyway, QRecall ran its regularly scheduled archive action at 6:00 PM today, and finished about 6:02 PM. There were no errors (I double-checked to log file to be sure.)

At 6:12 PM, Time Machine ran, but it failed to complete its backup. I checked the system.log file and found the following entries (I added some line breaks so you wouldn't have to scroll horizontally to read this message):

11/12/08 6:12:35 PM /System/Library/CoreServices/backupd[9020] Starting standard backup 

11/12/08 6:12:35 PM /System/Library/CoreServices/backupd[9020] Backing up to: /Volumes/G-Drive/Backups.backupdb 

11/12/08 6:12:36 PM /System/Library/CoreServices/backupd[9020] No pre-backup thinning needed: 1.30 GB requested

          (including padding), 267.61 GB available 

11/12/08 6:12:43 PM /System/Library/CoreServices/backupd[9020] Stopping backup. 

11/12/08 6:12:43 PM /System/Library/CoreServices/backupd[9020] Error: (-43) SrcErr:NO Copying /Users/bgiles/Library

          /Preferences/QRecall/Actions to

          /Volumes/G-Drive/Backups.backupdb/Bruce iMac/2008-11-12-181236.inProgress

          /7B68BD0E-3C7C-42B7-9E09-A19D98D3BCD7/Macintosh HD/Users/bgiles/Library/Preferences/QRecall 

11/12/08 6:12:43 PM /System/Library/CoreServices/backupd[9020] Copied 738 files (98.9 MB) from volume Macintosh HD. 

11/12/08 6:12:43 PM /System/Library/CoreServices/backupd[9020] Copy stage failed with error:11 

11/12/08 6:12:48 PM /System/Library/CoreServices/backupd[9020] Backup failed with error: 11

As you can see, it appears to have stopped because of a File Not Found (-43) error on the Actions folder in the QRecall preferences folder. Any idea why? A subsequent manual Time Machine backup completed without any errors and there's plenty of room (several hundred Gigabytes) on the backup drive.

-- Bruce

This is just confirming that the problem is fixed. As far as I can tell, deletions are working just fine, no matter what the compression level.

James Bucanek wrote:Version 1.1.0b36 should fix this problem.

I only had time for a few quick tests tonight, but it does seem to have fixed the problem. Everything I tried worked perfectly. I was unable to duplicate any of the problems I had before. I'm going to let it do a full, new backup tonight, and I'll do some more extensive tests tomorrow evening and report back.

I really do like the capability to delete items. It comes in handy when I do something like forget to tell QRecall not to back up my podcasts folder, which contains multiple gigabytes of audio and video files that change daily, and don't really need to be backed up.

James Bucanek wrote:Bruce, you are a genius!

Well, yeah, I know.

The release was already held up because I have one user who's archive occasionally gets damaged during a merge. So far the problem would only occur about once every three weeks and I had yet to reproduce the problem here. QRecall reports the same failure as the one in your logs. If the problem is related to compression, I should be able to reproduce and fix both.

Cool. I hadn't been changing the default compression level for quite some time, but I decided to try a new backup from scratch with the rc, and for some reason, I decided to change the compression level before I started. Everything seemed to be fine until I tried to delete an item.

If you ever want to quit that high-paying government job and work as a full time QRecall tester, just let me know.

Actually, I'm in private industry these days, but if you can match the salary, just let me know!

James,

I hate to throw a show-stopper at you now, but I've discovered a problem. If an archive's settings are set to the "slower, smaller" side (all three of the settings), then whenever I try to delete an item from the archive, it fails and I get a message that the archive is damaged. The repair appears to succeed, but every time I try to delete another item, the same kind of failure occurs.

If the archive's settings are all set to the "faster, larger" side, the problem does not occur. However, if I then, after a capture, change the settings to "slower, smaller" and compress the archive, then subsequent attempts to delete items from the archive will fail.

I sent you a report after numerous tests. In the tests, the archive called "Test 1" was initially set to "faster, larger" (the default), while the archive called "Test 2" was initially set to "slower, smaller". You'll see that item deletions from Test 1 succeeded every time, until I changed the settings and compressed the archive, after which they failed every time. Item deletions from Test 2 failed every time.

An update. I'm not sure how long QRecall appeared to do nothing before it finally started capturing files, but it was well over an hour, maybe an hour and a half. It did eventually start, however, and finished not long after that. As far as I can tell, it captured everything it should have captured, correctly.

The log file is interesting. I see log entries for every home directory on our server, like this:

2008-06-13 21:39:27.813 -0400 #debug# user 1026 (jhartis); home directory '/Network/Servers/server1.xxx.com/Users/jhartis' does not exist, user ignored [2.733206.364.40]
2008-06-13 21:39:27.813 -0400 #debug# user 1026 (jhartis); home directory '/Network/Servers/server1.xxx.com/Users/jhartis' does not exist, user ignored [2.733206.364.41]
2008-06-13 21:41:57.855 -0400 #debug# user 1027 (skarnitz); home directory '/Network/Servers/server1.xxx.com/Users/skarnitz' does not exist, user ignored [2.733206.364.42]
2008-06-13 21:41:57.855 -0400 #debug# user 1027 (skarnitz); home directory '/Network/Servers/server1.xxx.com/Users/skarnitz' does not exist, user ignored [2.733206.364.43]

I'm not sure what's up with that. Note that this copy of QRecall isn't running on the server, it's on my MacBook Pro, which happened to be connected to the network while the backup was running. I've obscured part of the domain name that's included in the paths above. I'll send you the unadulterated log file privately.

-- Bruce

James,

I'm seeing what I *think* is an unusual delay when capturing. This started with the release version of QRecall, but at the moment, I'm trying the 1.1.0(6) beta, and I'm still seeing it -- at least on the first capture.

This is starting with a new empty archive, and I did a verify disk and repair permissions on the source disk before I started.

I opted for the first test to capture my home folder, which is about 8.5 GB in size. I used the capture assistant to do an immediate capture (i.e. I haven't created any actions yet).

At the moment, the capture window is open, the dropdown panel at the top says "Capture bgiles to MacBook Pro Archive.quanta", the progress bar is in barber pole mode, and it says "Capturing" below that. The problem? It's been doing that for 20 minutes now. It hasn't captured the first file yet. Yes, I'm pretty sure. The capture file is 32.1 MB in size, and the modification date/time is about 20 minutes ago, when the archive was created.

I really don't have much stuff in the home folder on this machine. A couple of ripped DVDs accounts for a significant portion of the 8.5 GB.

I usually back up this computer weekly, and I noticed a similar problem this morning, when it was still running the previous release version of QRecall. When it happened this morning, I was busy doing other things, so I'm not sure how long it took before it finally started actually capturing files, but it was at least an hour. Eventually, the capture did complete.

I was hoping the beta might fix this, but apparently not. Any idea what the problem is? I'm running Leopard 10.5.3, with all the latest updates. security patches, etc.

(It's now been 27 minutes, and nothing has changed. I'll let you know if it eventually proceeds.)

-- Bruce

James Bucanek wrote:I have no idea what happened. But if I had to hazard a guess, I'd say that QRecall captured the Dock's preferences while the file was open and only partially updated.

Could be, although I have no idea how that could have happened either. Backups run at 2:00 AM, so that would have been hours after any changes I made to the dock.

I'll chalk it up to a fairly harmless mystery.

-- Bruce

I had to use QRecall to restore our server from a backup today, due to an update from OS X 10.4.10 to 10.4.11 that went horribly, horribly wrong. Fortunately, I expected trouble, so immediately before attempting to install the software update, I did a full backup, followed by a verify.

My external backup drive was bootable, with a minimal version of 10.4.10 on it, and the latest copy of QRecall. So, I booted from the backup drive, then used QRecall to restore the internal hard drive.

There were no errors during the restore process, and the system subsequently booted and appears to be running just fine. There was just one minor problem and that was that several of the dock icons were wrong. None of the icons that were in the dock as OS X ships were wrong. The only problem icons were the ones that I had dragged to the dock sometime later.

For instance, I had added Console to the dock. After the restore, the icon still said "Console" when the mouse hovered over it, but it was an Interface Builder NIB icon. Clicking the icon in the dock launched Interface Builder. Control-clicking on the icon and choosing "Show in Finder" showed me a NIB file from somewhere deep in the Developer folder, nowhere near the Console.app.

The problem was easy enough to fix. I just dragged the problem icons off the dock, and then dragged the proper ones back on. I haven't noticed any other problems. Do you have any idea what happened, and why?

-- Bruce