QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: Ralph Strauch
Forum Index » Profile for Ralph Strauch » Messages posted by Ralph Strauch
Author Message
This is not so much a bug as simply a report of qrecall's behavior under stress. While I was backing up my MBP this morning I meant to disconnect a USB peripheral that was plugged in and pulled out the firewire cable to my backup drive instead. Qrecallmonitor showed no sign of destress and looked like qrecall was just chugging along so I plugged the cable back in to see what would happen. Qrecallmonitor continued to show the backup as occurring, with time continuing to change but with no additional items being backed up.

I tried to stop the backup by clicking on the x in Qrecallmonitor, with no response. Quitting Qrecall didn't help either. I eventually had to quit Qrecall Helper using Activity Monitor. I then restarted the backup and it quickly repaired the archive and the backup.

While it would have been nicer if the interrupted backup had responded to my attempts to quit from Qrecall Monitor, I found this behavior overall acceptable and a big improvement over the way Qrecall used to handle such interruptions the last time I had one a year or so ago.

Thanks, James. Sorry I missed the info box.
As I understand qrecall, when I merge layers I create unused space within the archive file which gets used in subsequent backups, so at any point in time only a portion of the space the file takes up on disk is in use. Is there any way of knowing how large the actual archive is, and how much free space exists with the file, without actually compacting the file? It would be nice to know that, I think. I'm sorry I didn't think of this in time to suggest it for a feature in 1.1.1, if it's easy to put in.

You might try closing other apps when you do a backup, to minimize the number of open files the system has to deal with. That should at least confirm or eliminate that as the source of the problem.

James Bucanek wrote:Another option, and the one I'm most fond of, is to implement a column browser mode.

Anyone have any input or reaction to these suggestions?

I'd be in favor of the column browser mode. It solves the "going back" problem with the single window, and avoids creating an increasingly cluttered window as you browse like the disclosure triangles do. Keeping the ability to see what layers contain a version of each folder/file is important, too.

Here's the dump. Even zipped it turned out to be bigger than my smtp server would accept, so I'm attaching it here.

I'll run the dump later this afternoon when I've got some time away from the computer. Is this problem at all related to the duplicate entry problem I ran into with v1.1.0.12 (reported in the thread "scheduler gone missing")?

Could the problem be related to the fact that my "Owners and volumes" tab has a duplicate listing for my drive. The duplicate apparently got created back in March, when I first started using qrecall. All the layers that were in it have since been merged into the active listing for that drive, but the duplicate listing remains. I think we discussed this at one point and you said that the duplicate listing wasn't a problem, but I can't find the discussion anywhere. I'm wondering, though, if that is the problem, if I need to dump my current archive altogether and start from scratch?

If any of this would be easier to deal with by phone, my number is xxx-xxx-xxxx and I should be free today from 11-1, and after 2, Pacific Time.

I just updated to and did a backup. The activity window is hung at "Stopping" and the log indicates a command failure and incomplete capture. I've opened the archive twice and it doesn't sow the current backup at all. Each time I open it, creates a log entry that the "Archive contains auto-repair information.

I've sent the logs in from the app. You should have them now.

Should I go back to the previous version to rerun the backup?

After backing up with v1.1.0.12 the archive needed reindexing so I did that. When the process finished i got an error message telling me it had failed. Looking at the log it appears that the failure occurred early in the process, but it didn't stop the process or notify me till the end. My compressed log file is attached.

I guess the thing to do now is to repair the archive, but I'll wait on that till I hear for sure from you.

Try uninstalling QRecall (hold down the Shift and Option keys and choose QRecall > Quit and Uninstall). Then relaunch QRecall and reauthorize it (QRecall > Preferences... > Authorization).

That did it. Thanks.

Thanks for the explanations, James. I'm glad I asked before I set it up. I'll probably keep using Apple's Backup for the offsite backup. It does work, but is a far less elegant solution than qrecall.

I downloaded the beta tonight and opened it from the dmg to take a look at it and see what was different. I thought I'd wait for the release version, though, to make the switch. I ejected the dmg and tried to back up using v1.0.1 and it told me I had the wrong scheduler and needed to quit and restart to reinstall the scheduler. I did that several times without success. So then I decided just to install the beta and run from that. Now I'm getting the message that qrecall can't contact the scheduler, and restarting qrecall doesn't help. What do I have to do to reinstall the scheduler so I can use the app again?

I currently use Apple's Backup program to maintain an offsite backup of important files on dot Mac (soon to be mobileme), and I'm wondering if qrecall might do a better job. I'd like to check out some of the assumptions I'm making about how things work over a network, though, and get any other thoughts you might have before I try it.

Would the processing reduction gained by using smaller archives make it worthwhile to have separate archives for different groups of files, particularly for groups of files that I might want to update less frequently?

Capture compression should reduce the amount of backup data to be transmitted, but would it also impose additional interchanges between qrecall and the archive that would negate these savings?

Would merging and other management processes be inordinately time-consuming over the internet?

Do you have any other thought pro or con about using qrecall over the internet?

I'd like to add another vote for this feature. Being able to keep track of when significant changes were first backed up could be an extremely useful feature.

James Bucanek wrote:
This is the third request I've received for this feature, but I'm very reluctant to implement it. Macs have a single programable wake up timer. To change it would mean overwriting whatever wake up time you currently have chosen. Then what happens if you create two actions that run at different times that both want to wake up the system? Then what happens if you go back into the system preferences and select a new wake up time? Basically, I'm not a fan of applications that start changing system-wide preferences

Great explanation. Thanks.
Forum Index » Profile for Ralph Strauch » Messages posted by Ralph Strauch
Go to:   
Powered by JForum 2.1.8 © JForum Team