Gary K. Griffey wrote:The volume being captured in this case is an SMB share on a Windows server machine

Try copying the file to a local Mac volume, delete the file on the server, and then copy it back.

Gary K. Griffey wrote:errno: 93

Error 93 is ENOATTR (Attribute not found). It means that QRecall got a list of all of the extended attributes for the file, but when it went to read them one of them wasn't there.

This is either a transient problem, which won't repeat and can be ignored, or something else is odd with the volume structure. See if it happens again. If it does, try repairing the volume and capture again. If that doesn't resolve it, send a diagnostic report.

It is only a "Caution" so I would imagine it could be ignored?

In general, failing to capture extended attributes isn't a serious problem because they typically don't contain information critical to the use of the file.

QRecall 1.2.0b70 is ready. Upgrade and see if these problems are resolved.

Gary K. Griffey wrote:This seems to be related to beta 69

It is.

It's a side effect of the change to how finder metadata is captured. The change results in all items that have finder metadata stored in a com.apple.FinderInfo extended attribute to get recaptured in 1.2.0b69.

But this change broke the capture logging. The code that makes the capture decision and the code that tries to figure out what changed and log it are different blocks of code. The finder metadata change in b69 causes the files to be recaptured, but then the code that logs the difference can't find any difference (because, logically, there isn't any). So it logs "unknown".

Straightening this all out has revealed a far more subtle bug that would cause some items to be unnecessary recaptured. I'm testing the bug fixes now and a new version should be out in a few hours.

Gary K. Griffey wrote:I know I asked about this before...but I just wanted to follow-up. Is there anything in the works that would allow me to run a QRecall action from an Automator or Apple script?

I currently have some kind of AppleScript/Automator support on the to-do list, but it's still on the back burner.

Much more immediate is work that's being done to create a QRecall command-line tool. This already exists, in a primitive form, and is currently being used for development, testing, and diagnostics. The goal is to polish it up and turn it into full-feature command-line tool that could be invoked via shell scripts or Automator.

Steven Arnold wrote:I'd like to remove all copies of a specific file from all layers of my backups. How do I do this?

Open the archive and select the item(s) you want to delete.
Choose Archive > Delete Item...

David Ramsey wrote:I think I've got it: created one action to handle to backups and another to handle the rolling merges.

Correct.

It's also recommended that you schedule compact and verify actions to run periodically (approximately once a week). The compact action performs housekeeping, consolidation of unused space, and optimization. A verify action confirms the data integrity of the entire archive and will alert you of any data corruption that might have occurred.

David Ramsey wrote:Apparently there is a QRecall manual. If so, where can I get it?

In the QRecall application, choose Help > QRecall Help. The QRecall help was recently rewritten in its entirety, so feedback is welcome.

So far I'm impressed with QRecall running on Lion.

We're very glad to hear that.

Based on what I've seen so far with my QRecall trial, the advantages Time Machine has are:

1. Somewhat simpler U.I. (Of course it does less, too, but the QRecall interface can still be a little daunting, especially when you open a folder with a lot of files and see all those "timeline lines". It's kind complex visually.)

I'm compelled to note that you can turn timelines on and off as desired (View > Show/Hide Timelines).

2. Its deep integration with OS X means you can do things like recover individual Mail messages. And you have the option of restoring directly from a Time Machine backup when you install OS X.

Absolutely. Apple can do things with Time Machine that third party developers can't touch. Apple has even changed how the HFS filesystem work, just to make Time Machine's job easier.

Apple's overriding goal with Time Machine, however, is simplicity. Which is great. We think everyone should be making backups, and anything that makes that easier is welcome. QRecall's goals are data integrity and efficiency, and we think there's room in the universe for both approaches.

3. Time Machine consolidates backups (i.e. hourly backups for the last 24 hours, daily backups for the last week...) and automatically deletes older backups as space is needed.

...

For #3, the backup consolidation doesn't seem necessary with QRecall since the incremental "quantized" backup means the individual backups are typically much smaller. But what happens when the backup disk fills up? Do I delete older backups manually somehow?

QRecall can/will do exactly the same thing (it's called "rolling" your incremental backups). The different between QRecall and Time Machine is that in QRecall you can specify exactly the scope, frequency, and granularity of the roll. And like Time Machine, you can also make these actions conditional on the amount of free disk space available (or not). Again, you get to decide the strategy that makes sense for you.

I'd suggest using the Capture Assistant (Help > Capture Assistant) to create a backup strategy. The assistant will create actions that "roll" your incremental backups on a regular schedule. You can then open those actions and see how they are set up and adjust them as you see fit.

To read about automating QRecall in general, see the Guide > Automation > Action section in the QRecall Help. To learn more about rolling your incremental backups, see the Guide > Automation > Actions > Rolling Merge section.

Gary K. Griffey wrote:Report sent..

Thanks for the report.

Looking at the problem, it appears the helper process is crashing when it tries to load one the application preferences (which is very strange). This might turn out to be problem with the Mountain Lion beta, but I'll see if I can find a workaround.

Gary K. Griffey wrote:Are you interested in receiving bug reports, etc. for 10.8 at this point...or is it too early in the cycle?

It's not too early. In fact, one of my first to-do items was to start testing 10.8 following the release of QRecall 1.2.

For future reference, the answer to the question "should I send a diagnostic report?" is invariably "yes!"

Damian Huxtable wrote:Is it possible to add the "until" option as in the actions menu option, so I don't have to open Qrecall for this?

It's possible, it just wasn't practical for this release.

The "until" option requires a bunch of extra code that the monitor process isn't linked to. I have plans to address this, because there are some other commands I'd also like to monitor process to be able to perform (but can't because of this code sharing issue).

I've added this as a to-do item for 1.3.

That's an almost impossibly complicated question to answer, since it depends on so many variables—how big your archive is, how big the various archive indexes are, how much physical RAM you have, how many processor cores you have, and so on.

In broad strokes, QRecall will use as much memory as it can. There are several large data structures that QRecall creates during a capture. The larger these cache and lookup tables are, the more efficiently QRecall can preform the capture. So it can be agressive about allocating very large tables, but it tries to limit their size so they don't exceed more than 75% of your physical RAM. (If the tables get too large they get swapped out to the VM backing store, which significantly reduces the efficiency of having created a large table in the first place. So it's a delicate balance; too small and the capture is slow, too big and the capture is slow.)

If you feel QRecall is using too much RAM (or would like it to use more), you can adjust QRecall's memory usage by overriding the amount of physical RAM QRecall thinks your system has. To do this, set the QRPhysicalMemoryMB advanced setting to the number of megabytes of RAM QRecall will try to live within. Set it using the Terminal command, like this:

defaults write com.qrecall.client QRPhysicalMemoryMB -integer 2048

Note that QRecall never tries to use more than 6GB of RAM, regardless of how much physical RAM you have (or what the QRPhysicalMemoryMB setting is).

Steve Mayer wrote:In the activity window, it showed that it was going to execute at 7:00AM. It had NOT run at 6:00AM as scheduled.

First, thanks for the diagnostic report. The confusion is the type of schedule chosen for this action:



This particular action is, indeed, scheduled to run at 7:00 AM on March 18. Just as it was schedule to run at 6:00 AM on March 11.

The confusion occurs because an Interval Schedule doesn't change with your local time zone. It starts at a fixed point in time (in this case 6:00AM 8-Feb-2012) and then calculates exact time intervals—in this case 1 week, or 168 hours—after that time.

Since your clock shifted over the weekend, the "clock on the wall" time of the action changed from 6:00 AM to 7:00 AM, because if you waited until 6:00 on March 11 and then started a timer, waited exactly 168 hours, and then looked the clock again, it would read 7:00 on March 18.

If you want actions to run at a particular time in your local time zone, use a Daily Schedule.

This should be working. I built a test program using the code that QRecall uses to calculate dates for a daily schedule, and ran it starting last week after setting my system to the PDT time zone. On the DST transition this past weekend, the absolute date (GMT) time shifted one hour, just as it should. So as far as I can tell, QRecall should be calculating the correct start time for each day.

Editing the action shouldn't make any difference. Restarting the scheduler (i.e. your computer) might make a difference, but it's not supposed to.

Steve Mayer wrote:This morning, the job was wanting to kick off at 7:00 AM PST according to the activity list.

Did it actually run at 7:00 or did it just say it was going to run at 7:00 in the actions window and/or the activity monitor window? After it ran, what time did it say it was going to run tomorrow?

I edited the action and it still said that the job would occur at 6:00 AM

Did you mean to write "7:00 AM", or did it change to the correct time?

Let me know if you need any more info.

Please send a diagnostic report.

P.S. I hate daylight savings time. I vote to abolish it.

pirem71 wrote:It would be nice if I can select a file in the file browser pane and then launch the command "Recall all versions". The command will create a folder containing all captured versions of that file (identified appending capturing date).

That feature (or some varient thereof) has been requested before. There is a solution in the works. With any luck, it will make it into 1.3.