At least in my case, exclusions are important to honor consistently, and not just attempts to optimize archive space. As such I'd be nervous about too much magic in the overrides and would advise against attaching "ignore the exclusions" to anything not clearly labelled as such. "Deep scan", for example, would be a bad choice.

Of the options presented, I actually think the original plan of requiring adding the top level exclusion to the capture and only ignoring that one exclusion is the best. Its the least surprising (when documented) in the sense that it has the fewest side effects. Its explicit and can be as fine grained as the user desires.

QRecall will reinstall the new service and notify OS X that it is available. Afterwards, it should appear in your Services Preferences.

Thanks, that worked...

This is exactly the "mistake" that the new exclusion arrangement is designed to prevent you from making. Here's the problem with the way it works in QRecall 1.2:

<snip>

I understand your explanation, but I think its pretty surprising. Why would exclusion translate to a deletion in the archive? I would understand if exclusion translated to removal of all previous versions (CrashPlan works this way, with appropriate warnings). Presumably deletion is a recorded event, and clearly you can carry files unchanged forward through the layers for ignore changes. Can exclusions not be "ignore changes indefinitely"?

Also, could you clarify "captured as if they are brand new"? For unchanged files, the blocks are the same, so aside from the metadata of the files reappearing in the next layer, I presume the impact is small.

That's exactly why there's an exception to the rule: an ignore preference set on a folder is ignored when that folder is explicitly a target of a capture action.

If you capture a folder, and that folder is set to ignore changes, the changes may, or may not, be ignored (it's a bug and it depends on where the folder is in the hierarchy).

I'll try it in the next beta, thanks. You'll definitely want to mention this in docs, I would have assumed it worked according to the rules you mention as a bug.

Alex

Trying the 2.0 beta, and I find the new exclusion rules to be less useful than their 1.x counterparts.

- First, despite rebooting, copying QRecall.app around, etc. I can't get LaunchServices to see the new "QRecall Capture Preferences" service. I do have "Capture to QRecall Archive", etc.

- While I understand the value of exclusion filesystem attributes for items that may move, I'm actually much more concerned about never capturing items at particular paths. These are folders that may be deleted and recreated, and thus attributes will be lost. The good news here is that per-archive exclusions may work, except...

- The loss of exclusions per capture mean that one cannot set independent schedules for an item that is a subitem of a larger capture. For example, I backup my boot drive frequently, but exclude a subdirectory of VM images. However, previously the VM images could be captured on a separate event by a capture with a different exclusion set. Note that the "Ignore changes" option for capture preferences is not a good replacement, as it forces me to only ignore on a schedule whose timeline is opaque, I can't force a capture on an event (say, when VMWare quits).

Finally a couple of UI issues:

- The exclusions scroll view in Archive settings is small, and cannot be resized. For exclusions inside ~/Library or long lists it's a frustrating interface to verify that all the items you want are present. This was not an issue with the prior interface in the capture action.

- If one does choose to use capture preferences as extended attributes, there's no simple UI to actually see what's excluded. Again this is necessary to verify you haven't missed something that should be excluded.


Some of these issues can be addressed with UI fixes, but its not clear to me that the new exclusion model actually supports the same set of features as the prior design.

Thanks,

Alex

Facing a 7+ hour verify, I think my final configuration will need to have the server do the verification and compacts of archives from the laptops as suggested in several forum threads. I assume if I install QRecall on the server with its "Start and run actions while logged out" enabled, the actions will run (I understand I'll need to have appropriate filesystem permissions for QRecall on the server).

However, it doesn't appear that on a headless server a verification failure has any place to warn me. Given my experience so far with handling fileserver disconnects I'm guessing I'll see verification errors with some regularity. How can this be handled? The discussion of autorepair in the manual focuses primarily on the client repairing during capture. However, in my logs I see messages like:

Action 2014-11-14 18:00:01 Failure Capture failed
Action 2014-11-14 18:00:01 The index of the archive is incorrect and needs to be recreated.

I presume a repair would have fixed these (in my tests I just ended up recreating the archive).

Specific questions:

- This old thread http://forums.qrecall.com/posts/list/118.page#488 mentions email notifications, was that ever implemented?
- Is it possible to chain verify to repair on the server action?
- If the server verification fails is this guaranteed to trigger a warning and eventual autorepair on the status on the client? Will the client's status window show the verification state produced by the server (i.e. is the verification failure persisted to the archive for other readers)?
- Will the server repaired archive trigger recapture of corrupted files in the archive from the client?

Thanks,

Alex

While testing QRecall as a Time Machine replacement, I've had 3-5 monitor crashes. Where can I send crash reports? I'd prefer not to send a "diagnostic" report whose contents I cannot audit, and it appears there's no support address for presales users.