AZ 2011 wrote: I have gone to Preferences -> Authorization, clicked "Preauthorize..." and entered my administrator username & password. The dialog closes with no indication of success or failure, but the log message suggests to me that it isn't working.

That's definitely the correct way to do it, so something is clearly wrong. First, send a diagnostic report (Help > Send Report...) and I'll look for clues.

Try uninstalling and reinstalling QRecall. In the QRecall application, hold down the Command+Option keys and choose QRecall > Uninstall and Quit. Start QRecall again, go the preferences, and Preauthorize again. See if that improves the situation.

Is the account you have QRecall installed in an admin account? There are new security restrictions in OS X that make pre-authorizing QRecall for use in a non-administrative account problematic. If you need to run QRecall with admin privileges, my recommendation is to install and configure QRecall from within an administrator's account.

Johannes wrote:Hi,

Hi!

- ~/Library/Cache is not excluded even if the option "exclude Cache files" is checked

I don't see that behavior here. Please send a diagnostic report (Help > Send Report...). There might be some clue as to why those filters aren't working.

- The Date/Time column in the Log Window is a bit too small and truncates the second figure of the minutes. See screenshot. Not a major issue but when testing things the minutes are important

I also don't see that here. In the screen shot, your font is bigger than what I see on any of my test systems. Have you used a utility to alter the system fonts or their default sizes?

- Growl notification seem not to work

I'm getting them. I'm running Grown 1.2.1 and (as far as I know) QRecall uses the latest Growl interface library. Make sure you have notifications from QRecall enabled. You might also try restarting Growl (or your system) and see if that fixes it.

- give me an option to ignore files that I have no permission for. I don't want to run my backups as root, but I have a few session files in my Sites folder that are owned by www. No need to backup them. But QRecall alerts me of the "problem" every time.

I'll add that to the wish list. I have a number of advanced filtering options planned for a future version. Filtering based on permissions could easily be added then.

So far for now. All in all I am very pleased after the first testing.

Welcome aboard, and keep those bug reports and feature requests coming.

Adam Horne wrote:So I just purchased a beast of a external HD (2TB io Safe)

Very cool. I didn't even know they made waterproof disk drives.

I'm going to create an archive of JUST homefolder and just place that on the OS partition.

I'd recommend capturing your entire startup volume as your baseline (i.e. once-a-day) routine. If you've gone to the trouble of creating a partition with a bootable OS and a copy of QRecall so that you can make quick recoveries, this will save you if you experience a total meltdown of your boot drive?but only if you have a complete capture.

Without capturing your entire volume, it will totally spoil the mood. You will have to first find your Install DVD, go through the OS install process, reboot and upgrade the OS, restore your home folder, then manually reinstall all of your applications. If you're going to go through all that, having a bootable partition is somewhat moot.

The advantage if the bootable partition is that if something catastrophic happens to your boot volume, all you have to do is boot from the recovery partition, fire up QRecall, perform a full restore of your boot volume, restart and go right back to work. But this only works if you make regular backups of your entire boot volume.

- Is that the correct method for a proper backup regarding the HomeFolder? Or should I do an actual startup folder backup?

My advice? Capture your entire startup drive every day. In its QRecall form, your entire operating system will take up less than 2GB. That 0.1% of your new drive. Well worth the tiny bit of storage.

- I'm an artist and work with particular folders often and want to set hourly captures of them. Do you suggest that I set up a new action rule in my HomeFolder archive; to capture my folders every hour? I'm thinking that I should set up an whole new archive to capture the folders and place that on my (Personal) partition.

Don't create another archive. That just makes QRecall do double the work, use (nearly) twice as much disk space, and complicates the restoration process. Create a second (or third) action to capture your working folders for more agressive backups. On my system, I capture my startup drive once a day, my home folder every two hours, and just my "Projects" folder every 20 minutes.

- If I capture my HomeFolder and set it for daily captures, how often should someone verify the backup? Would a weekly verification be enough or should I do them more often?

I recommend verifying your archive about once a week.

Is it safe to compact the HomeFolder archive?

Safe as houses.

Also, I might have messed up on this but I made the OS Partiton no bigger than my working computers partition. I'm going to assume that QRecall wont have much play when it comes to rolling merges, so should I set up a new partition with added storage?

I'd recommend a backup partition between 1x and 1.5x the size of the data (not the volume) you want to capture, depending on how much history you want to maintain. So if your current drive is less than 65% full, then you have plenty of space for your archive. If you tend to fill up your drive, or generate big changes, I'd increase the size of your backup partition by 50%.

For most situations, QRecall can keep a year's worth of weekly incremental backups using between 1.2x to 1.5x the size of the original data on the disk. For example, my Mac Pro has a 740GB boot drive that's about 70% full (around 540GB of data). I have a 70 layer archive that's keeping incremental backup going back a year and half. That archive is 923GB, or 1.7x the size of the data on the disk. And remember, you can alway turn on QRecall compression if you want to reduce the size of the archive.

- I have some files that are on a PC. My iMac(which the Ext. HD is connected) and my PC share the same home network, with a cat5 cable running to each(no wireless). I would like to capture some partition drives off of my PC. No windows files, just media files(mp3s, avi's, various documents). Any way to create a backup method for them?

QRecall will capture (almost) anything that can be read by OS X. There are some permission and restore issues the can occur when capturing or restoring files from a non-HFS file system, but for plain vanilla files these are negligible. Just set up a QRecall action to capture the folders from your shared volume. If this is a networked volume, you might want to set the action up to run when the folder mounts. Otherwise, if the action is scheduled to run and the folder isn't mounted, nothing gets backed up.

Some of the drives are rather large (300 GB is the largest) so I'm assuming that it would take massive time to do this over cat5.

It depends on what your network speeds are. 100Mb Ethernet can move ~600MB/minute, so an initial 300GB capture would only take 8-10 hours (to a local hard drive). And remember, after the initial capture QRecall only recaptures what changed; subsequent captures will probably only take 10 minutes or so. Gigabit Ethernet can approach hard disk speeds.

- I have Drive Genius 3 and DiskWarrior. Should I run some of these programs monthly for preventative measures? DiskWarrior recommends that you run their program on your HD once a month. I'm kind of the guy that likes to do scans to prevent any hiccups, but I know that sometimes I should just let things be...

In general, don't worry about it unless something goes wrong. QRecall is downright paranoid about data integrity. If anything looks wrong with the data in your archive, QRecall will immediately stop. Your weekly verify will validate every single bit of data in your archive. If even a single hair it out of place, it will let you know. If the verify give you a clean bill of health, you have nothing to worry about.

If an action or verify does report a problem, then the first thing to do is repair the archive's volume using Disk Utility, Disk Warrior, etc. Then repair the QRecall archive. Many QRecall data integrity problems are really caused by corrupted volume structures, and trying to repair the archive before repairing the volume can actually cause more damage.

Here's my final recommendation: Start by using the capture assistant to create a backup strategy. Set it up to keep your data "as long as possible." Take a good look at the actions created by the assistent, and then tweak them as desired, change their schedules, whatever. Then add a verify action that runs once a week and any additional capture actions (like your Documents folder) that you want to run during the day. Once you have that all working, repeat the process with your networked volume of media files.

Good luck,

Adam Horne wrote:So my question is if set a merge action in QRecall, could I lose some of the zipped files that haven't been touched in months? If I set it to merge the past (1) months worth of layers, could I lose a file that hasn't been recaptured in months?

No, not unless you've deleted those files from the file system and performed another capture.

A merge creates a composite of the merged layers and preserves the merged results as a new layer. Within those layers, it always preserves the most recent information about each item. It doesn't matter how long ago a file was last captured; if the file still exists in the most recent layer, then the last captured version of that file is the most current and the one that will be preserved. The only copies of the file that might be deleted are any older versions of that same file that exist in earlier layers.

A file is completely deleted from the archive only after you delete that item from the file system, capture again, and then merge that layer with the earlier ones. In this situation, the "most current version" of the file is the fact that it doesn't exist, so QRecall discards all older copies.

Well that's not the only way. The special Archive > Delete Item... command will purge all copies of any item you choose from an archive. (Just so you know.)

Mike Haire wrote:When qrecall encounters a full disk during capture it will not stop. The capture ran overnight and the progress indicator was at the same position I left it 6 hours sooner.

That's odd. QRecall is usually extremely (some would say too sensitive) to disk full conditions. It actually goes out of its way to detect a disk full condition before it actually happens, so it can finish up in an orderly fashion.

The log indicates qrecall encountered a full disk and stopped processing.

Please send a diagnostic report (Help > Send Report). This will help let me review the actual log messages and try to determine what happend.

However, the application was still running and would not Quit. I performed a Force Quit, but the qrecall Activity Monitor showed that qrecall was still running.

The QRecall application is not the process that performs the QRecall actions. The heavy lifting is performed by a process named QRecallHelper. QRecall (the application) and the QRecall monitor window are just pretty faces to what's going on behind the curtain. To really kill a QRecall action that's running launch the Activity Monitor, find the QRecallHelper process, and kill that.

Qrecall would also not attempt to continue after I trashed some large files in order to give it some more space.

It's hard to say what's going on. If the QRecallHelper process was still running and had the archive files open, another QRecall action won't start until the first one is finished.

I ended up logging out and back in and then trashed the quanta file.

That will also kill the background helper process.

I'm running a Trial key before purchasing. I really like the concept behind qrecall, but this is a negative indicator to me.

Glad to have you aboard. Let's see if we can figure out what's going on and get you on track.

Maybe v1.2 will provide a fix?

The beta version has a lot of improvements over the current released version, some of which have to do with how QRecall deals with disk full situations. Since you're just starting out, it certainly wouldn't hurt to give the beta a spin.

Daniel,

Good suggestions. As for prompting, I too find myself in situations (mostly because I'm always installing new versions of QRecall for testing) where I don't want a bunch of scheduled actions to start running. Being able to stop them would be handy.

On my to do list is a feature request to put up a prompt/dialog before an action starts (this would be an option in the action's schedule), allowing you to start it immediately or cancel. If you don't respond to the dialog in 60 seconds, it would proceed automatically.

As for a "once action X has finished" event, how do you see this as materially different than scheduling the subsequent actions to run after the first? My original concept for a sequence of actions is that they would simply be scheduled to run in order (capture at 1:00, merge at 1:01, compact at 1:02). The scheduler automatically takes care of not running them concurrently.

Neil,

Thanks for sending a diagnostic report. It reminded me that there's one more requirement for QRecall to auto-mount your archive's volume:

(3) The action does not use the "Hold While No Archive" or "Ignore if No Archive" schedule conditions.

These conditions are intended for archives on volumes that can't be automatically mounted. They depend on you to mount the volume (such as physically plugging in a drive or connecting to a VPN) and then the action will proceed automatically.

The side effect of setting these conditions is that QRecall won't even try to mount the volume.

Bruce Giles wrote:I've noticed two issues with recent betas. I'm not sure if these are actually problems, or just due to the fact that these are betas.

They're actual problems.

1. In the QuickStart menu, the Check for Updates pop-up menu defaults to blank. If I click on the menu, I see "Manually", "Every Startup", "One a Day", and "Once a Week". There's a blank line below "Once a week", with a checkmark beside it. I can choose one of the other options, and it appears to work. If I click on the menu again, the blank line is gone, and the option I selected is checked, but after quitting and restarting QRecall, the blank option is selected again. Despite that, QRecall does notify me of new updates.

I'm pretty sure this one is fixed, because I remember fixing it. Unfortunely, it was fixed in the main development trunk, which is currently undergoing surgery and doesn't build, so I can't verify that. When it does build, I'll double check. It should show up in the beta sometime in the next month.

2. The second issue is that after every installation of a new beta, I get asked to authorize with my username and password. No problem so far. But then when I check Preferences, Authorization, the "Capture and recall items using administrative privileges" checkbox is checked, as I wanted, but the button below always says "Preauthorize..." So I click it, and it changes to "Cancel Preauthorization". It does not ask for my username and password again. I presume this is because it's only been a few seconds since I initially entered them, so that authorization is still in effect. My question is why the "Preauthorize" setting appears not to stick between installs. Should it, or is this expected behavior? Once I've set it to Preauthorize, it retains that setting until I install the next beta.

I just upgraded one of my test machines to b23, and I can confirm that this is happening. I'm not entirely sure why, but I'll investigate. I can confirm that the problem is just the button label. During the upgrade, the helper tool does get pre-authorized, but for some reason the preferences window doesn't see the change.

Neil,

For QRecall to mount a network volume while unattended, it requires two things: (1) the user name and password for the volume must be stored on your keychain, and (2) your keychain must be open.

The later also implies that you're logged in. Taken together, your computer must be logged into your account, and everything the system needs to mount that volume must be readily available without having to ask. If any of these things are missing, QRecall won't be able to mount the volume.

You can test this simply enough. Mount your network volume and create an alias to any file or folder on that volume. Save the alias on your local desktop and eject the volume. Now open the alias. If the volume mounts automatically, then everything should work. (The Finder and QRecall both call the same framework to mount volumes that contain the target of an alias, so if it works in the Finder it should work for QRecall.)

There is one last caveat. The alias stored in the action that points to your remote archive must be up to date. If not, QRecall might not be able to identify the volume that needs to be mounted. If you suspect this, mount your volume, open the Actions window, open the capture action, reselect the target archive, and save the action.

Now if all that goes well and QRecall still isn't mounting your volume, send a diagnostic report.

Gary K. Griffey wrote:You mentioned that the v19 beta release had some debugging code removed...were there other changes as well?

Nothing significant, beyond the changes to how concurrent operations are handled. I would not expect that to significantly affect capture performance.

The performance I am seeing, at least thus far, seems to be about what I was seeing in the latest production release. When I started using the beta I observed huge capture performance gains...this appears to be reduced in V19.

That's unexpected. It could be QRecall or it could be OS X 10.6.5. One thing I've noticed with 10.6.5 is processes spawning an inordinate number of threads. Even after the "fix" in b18 to address this, processes still run with considerably more threads than they did in 10.6.4. Yet while I find this perplexing, I still wouldn't expect additional threads to seriously degrade capture performance.

I'll investigate this here. One thing you can do is gather some samples. You, and anyone else reading this thread, are welcome to send a diagnostic report after running b19 for a week or so. Say something like "b19 performance" in the comments. I can then write a program to extract the performance statistics from the logs for the past couple of months and see if there's a correlation between the upgrade and a drop in capture speeds. I'd be particularly interested in getting a report from anyone who's upgraded to QRecall 1.2.0b19 but is still running OS X 10.6.4.

Glenn,

Thanks for the post, and for the sample.

It looks like QRecall is spending all of it's time reading, formatting, and sorting the items in the log window. If you close the log window does your CPU go back to normal?

The log window running one CPU at 100% (and also making the GUI sluggish) is known issue. One that's only made worse by the beta, because it records a lot more detail in the log. (Even the stuff you can't see in the log window still has to be read, decoded, and sorted.)

James G. wrote:OK, thank you for looking into it.

No problem. Please let me know what the outcome is, and you can put the Macfusion developers in touch with me if they have any questions.

James,

Your log file indicates that the file exchange request failed with an I/O error (-36).

2010-11-07 16:47:07.494 -0800 Failure Failed

2010-11-07 16:47:07.494 -0800 Details cannot swap files

2010-11-07 16:47:07.494 -0800 #debug# IO exception

2010-11-07 16:47:07.494 -0800 Details Path: /Volumes/x/Backup.quanta/layer_scribble.index

2010-11-07 16:47:07.494 -0800 Details Other: /Volumes/x/Backup.quanta/layer.index

2010-11-07 16:47:07.495 -0800 #debug# API: FSExchangeObjects

2010-11-07 16:47:07.495 -0800 #debug# OSErr: -36

Since there's actually not much I/O involved in exchanging files, and it happens every time QRecall attempts to exchange files on that volume, I'm going assume that it's a bug in the implementation of the filesystem.

I'll add it to the list of anomalies to investigate, and I might even be able to develop a workaround, but I would suggest that you begin by contacting the developers of Macfusion, and pass along this information.

James G. wrote:I'm getting the following error after a capture to an archive residing on an sshfs mount from Macfusion:

Problem closing archive: Cannot swap files

Wild guess: QRecall occasionally uses a filesystem call that exchanges two files. It's possible that your Macfusion sshfs mount either reports that it supports this feature when it doesn't, or it's improperly implemented.

Send a diagnostic report (Help > Send Report) and I'll look into the specifics of the failure.

Gary K. Griffey wrote:One other clarification...is there any way that hidden files/folders can be viewed in an archive? When you open an archive...these folders/files are obviously not visible.

Play with the menu commands View > Show Invisible Items and View > Show Package Contents.