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.

Michel Amyot wrote:I am testing QRecall right now and I like it a lot. But... because there is a but, is there a way to «delete» files from a layer?

Yes, but you'll have to wait 24 hours.

The new feature will appear in version 1.1.0(33) which is currently baking. It will permit you to delete all instances of an item from all layers.

The layer delete and merge commands delete items horizontally (deleting all old items across an entire layer). The new item delete command deletes items vertically (deletes a single item from every layer).

Is it hidden somewhere or is it prohibited?

It's not prohibited, it just took some time to get it functional.

Michel Amyot wrote:Is there a way with QRecall to perform such function?

QRecall is really designed to capture incremental changes of your file to an archive, not create more copies of your files.

Or could it be implemented in the future?

Currently planned for version 1.3 will be the ability to schedule an action to run when an item changes (this feature will require Leopard). You will then be able to create an action to capture your working project file or folder automatically every time it's modified.

If you need to recover an earlier version, select the document, right/control+click, and choose the Recall command (you can do that now).

An interim solution you can try now is to schedule an action to capture just your project folder at some reasonable interval. This is what I do with my QRecall project files. I have an archive just for the QRecall project, and an action recaptures the project folder every 20 minutes. Since QRecall only captures changes, most of the time the capture does nothing. I can recover any changed file going back a week with a 20 minute resolution.

You may think: «Who needs that kind of backup strategy?»

I don't have to ask.

The previous fix for the SMB volumes wasn't Intel specific and the problem being reported by the G4 is completely different than the problem encountered by your Intel system. I suspect that the old version of QRecall that had problems with the SMB volume on the Intel would have had the same problems on the G4. If it didn't have that same problem, then that would be interesting.

I also wouldn't be surprised at all if there were subtle platform-specific differences between the Samba drivers on the G4 vs. those your Intel system.

I was hoping you had an update.

I can find nothing in the code to explain what's happening. So for now I'm going with the assumption that the problem is coincident with using this particular storage device.

The first diagnostic is to try it with a different device. You were going to perform the same capture on the same machine using an external drive. Have you had a chance to do that, and were the results different?

Thanks!

Christian,

I'm glad to hear that things are working satisfactorily again. I'm mildly curious as to why the other capture was taking so long; maybe the log file contains a clue.

The issue of QRecall continuing to use an archive that's been dragged into the Trash isn't new. It's caught more than one user by surprise. I'm not entirely sure what the solution is, but I've made a note to try and deal with that situation in a future version.