This fix, along with a few other minor changes, have been rolled into release candidate 2. Launch QRecall (or choose QRecall > Check for updates...) to get the new version.

Bruce Giles wrote: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.

Well, it's a good thing you did or it might have taken a lot longer to figure this one out.

Version 1.1.0b36 should fix this problem. To install and test b36:

- Download the 1.1.0b36 disk image. Open the disk image to mount it.
- Open your Applications folder and locate the old QRecall.
- Drag the old QRecall application to the Trash. Do not attempt to empty the Trash.
- Drag the new QRecall application into your Applications folder.
- Open the new QRecall application in your Applications folder.
- You can now empty your Trash.

Bruce Giles wrote:I hate to throw a show-stopper at you now, ...

It's better than releasing a product with bugs.

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.

Bruce, you are a genius!

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.

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

Rob Wyatt wrote:I chose to split it into two capture actions so that I could backup my home folder every hour, but only backup the system when I felt like it (ie: after installing new software, at the end of the day, etc). I figured this might be faster than trying to capture my entire hard drive every hour. Maybe not?

You're correct in that a recapture of your home folder will be faster than trying to recapture the entire volume every hour.

This is exactly what I have set up on my main development system: Capture entire volume once a day, capture my home folder once an hour.

The problem is that when you capture the entire volume you excluded your home folder. Instead of creating a new layer that just picks up any changes made on the volume, you create a new layer that acts as if you deleted your entire home folder before capturing the volume. I',m sure that's not what you wanted.

Rob Wyatt wrote:Since I'm backing up to a NAS, when I log out, the capture action doesn't run. Is there any way to keep the volume mounted after logout?

For networked volumes, I don't know of any way of keeping them mounted after logging out.

QRecall will attempt to remount local volumes when logged out, allowing the action to run. Mounting network volumes, however, depends on system services (like the key chain) that are only available when you are logged in. This is mentioned the notes in QRecall Help > Automation > Scheduling Actions.

Or should I switch from AFP mounts to NFS? Wouldn't auto-mounted NFS shares stay mounted even when the user logs out?

I don't know. It's worth a try.

Rob Wyatt wrote:I currently have two actions set up. One captures my home folder every hour to my Thecus N4100 Pro NAS.

The second action captures my entire hard drive, minus the home folder (when I log out).

Rob, in our discussion of features I forgot to mention that this is probably not a good idea.

I'm sure you are skipping your home folder by excluding it in the filters second of the capture action. When you exclude an item, QRecall treats that item as if it did not exist. What you end up with is a layer containing your entire volume, without a home folder. If you were to restore that layer it would not contain your home folder.

In the action that captures your entire hard drive, it's best to include your home folder. Besides the reason just mentioned, that's the best time to capture your home folder because it's very stable while you're logged out.

There's little or no extra work involved (especially if you're using OS 10.5). Only changes made since you last captured your home folder will be captured.

Rob Wyatt wrote:How about this...add a condition that allows QRecall to request a shutdown after the user logs out AND the backup action is finished? It's a little confusing, maybe, but that way when I logout at the end of the day, QRecall runs, then tells my machine to shut down. Selecting "Shut Down" would, obviously, bypass this.

That's, more or less, what I had in mind. But just to give you some idea of the potential pitfalls, imagine scheduling a capture that runs at night and then shuts down. But then you shutdown manually. After restarting the next day, the capture runs immediately because it's overdue and then ... shuts down. Probably not what you want to happen.

Another option might be to alert the user upon logout that QRecall is going to run a backup and then ask if the user wishes to shut down when the backup is complete?

I agree that any shutdown option should include some sort of user interaction, just to avoid the situations like the one I just mentioned.

Thanks for the additional input. I'm always looking for ways to make QRecall more usable, and learning about how people use it, what they like and don't like, helps substantially.

I don't have any immediate plans for reworking the main interface, but when I do revisit it I'll take all of these suggestions into account.

Rob Wyatt wrote:Speaking of the Info drawer, another bit of feedback. It's hard to know what I dislike more, list views or drawers. I find drawers sliding out, windows moving off the edge of the screen to accommodate them, etc. rather irritating. I'm very much a fan of single-window UI.

I know opinions about drawers run strong. I can tell you that some considerable amount of time was spent making sure that the document window won't "move off the edge of the screen" to accomodate the drawer. The window will resize, if needed, when the drawer is opened and restore itself when the drawer is closed again.

Personally, I think the Info pane should *always* be visible and integrated into the archive window. From an ease of use standpoint, what does one really gain by hiding/showing this information?

The full amount of info consumes a lot of screen real estate. If you have a 30" Cinema display it's no big deal. But on a 13" laptop the One-Window UI is cumbersome. Try using the latest iTunes on a really small screen.

Secondly, even with a column view there's more information in the Info window than could be displayed in the summary column. And the Info drawer also displays information about groups of items, layers, volumes, and the archive itself. There's really no other place to display this and I suspect that I dislike dealing with multiple Info windows even more than you dislike drawers.

Rob Wyatt wrote:Now, how about the ability to run an action upon shutdown?

I would love to implement something like that, but it's darn near close to impossible. When you select Shutdown, the system proceeds to stop every running process. That includes QRecall.

There's no way to suspend or hold a shutdown request until something finishes. If a process doesn't quit within a reasonable amount of time (about a minute), the operating system forcibly terminates it. The OS certainly wouldn't wait for something as time consuming as a capture to complete.

GUI applications can refuse to quit, which will cancel the shutdown request. But canceling the shutdown defeats the purpose.

Having said that, I've considered a feature that would send a shutdown request to the OS after an action had finished.

Rob Wyatt wrote:That said, I really *dislike* list view. Have you considered implementing some sort of column view?

Yes, that's been mentioned a couple of times and is on the short list of new features.

What I'd like is the ability to browse my archive in column view. When I select a file, I'd like to see all instances of the file listed in the far right column. Select the one I want to restore and away I go!

That is, more or less, available now. Open the Info drawer (View > Show Info). Select a file and the info drawer will display additional information about the item, including the list of layers where the item was captured. Double clicking on an item in that list rewinds the archive to that date.

Thanks for listening!

Thanks for the feedback!

Open the archive document, open the Info drawer (View > Show Info), then make sure nothing is selected in the archive window. When no volumes, items, or layer are selected the Info drawer displays some general information about the archive, including the overall size of the archive and the amount of free space (if known).

Immediately after a Merge QRecall doesn't actually know how much free space is in an archive. In this case the amount free will display as "undetermined" or "at least XXXMB." The next Compact or Capture will begin by determining how much free space is actually available. While it's doing this it displays the status "Locating free space."

So after the next capture, you can open the archive and see how much free space it has.

If you don't want to wait for a capture, start a compact. As soon as the compact progresses past the "locating free space" phase and starts compacting, stop the action. The free space information has been updated at this point and you can view it in the browser.

Good eye!

Fixed.

I'd like to say that QRecall is that answer, but I'm afraid not. The very nature of QRecall makes splitting backups across removable media impossible.

I would check out Toast Titanium by Roxio http://www.roxio.com/enu/products/toast/titanium/overview.html. It can span large folders of data across multiple discs.

James Bucanek wrote:I have an archive just for the QRecall project, and an action recaptures the project folder every 20 minutes.

I should clarify that you don't have to have a separate archive to implement this kind of capture strategy, but it can improve performance if you plan to run lots of small capture actions.

As a counter example, I also capture my entire home folder (/Users/james) hourly. This is done to the same archive I use to capture my entire startup volume every night.

The difference is just performance. The amount of time it takes to open, update, and close an archive is largely dependent on its size and complexity. By capturing my working QRecall documents to its own archive means the archive is never very large and captures are extremely quick (most captures finish within 15 seconds).

Capturing my home folder to my primary backup archive takes much longer (several minutes) even when very little has changed, because my primary backup archive is about a 100 times bigger than my project archive.