I've made substantial rearrangement to my action schedule, with all except the ever-changing system folders on file change event-based schedules. It's a great feature for v2. Thank you very much. Two small issues arise out of this change, however.

1. Those event-driven actions take place more often than I expected due to meaningless (non)change to .DS_Store files. There are now numerous layers in those archives that contains nothing but one or two .DS_Store files. I know they take up very little space in the archives, and the layers will evently merge with those with substantive changes. And yet I still hope I can exclude all the .DS_Store files from most archives.

Currently there's no way to specify a .DS_Store file in archive settings UI because you can't select a hidden file. (The trick of using SHFT_CMD_G to go into hidden folders don't work here.) The "qrecall captureprefs" command works, but I wonder if the extended attribute QR uses would stick when OS X makes changes to .DS_Store files (I guess it depends on whether the system writes changes directly into existing files or creates a new one and then removes the old one).

More importantly, new .DS_Store are created all the time, and it's not practical to exclude them one by one. Hence my request: could you please allow more flexibility in this area? I would like to exclude, e.g., all .DS_Store files, all *.bak files, all *.*-journal files, and all "minidump" folders, just to name a few.

2. The current explanation for the option "Ignore new events for ___ (min./hours/days/weeks)" reads:

Ignore New Events

The ignore option will ignore new events that occur after the event that ran the action. To prevent new events from running the action again too quickly, choose the Ignore new events option and set a time period. The next event that occurs after the ignore period will run the action again.

I had taken it to mean--until I experimented with the option--file changes taking place in the "timeout" period would be backed up only when a new file change event after the timeout triggered the capture action. Should no new changes be made to the watched folders for a long time after the timeout, as a result, changes during the timeout would be without a backup for a long time.

In fact, QR behaves as I expect/want it to behave: all changes taking place during the timeout period are backed up as soon as the timeout period expires.

If my understanding is correct, I would suggest changing the option to something like "minimum time between actions" or "minimum time before the next action".

Thanks for listening.

Ming-Li Wang wrote:1. Those event-driven actions take place more often than I expected due to meaningless (non)change to .DS_Store files.

This, sadly, I can't do much about. OS X's file change event service doesn't report exactly what changed in the filesystem, just that "something in folder XYZ changed." So it's impossible to prevent changes to specific items from running an action.

I would like to exclude, e.g., all .DS_Store files, all *.bak files, all *.*-journal files, and all "minidump" folders, just to name a few.

This has been on the to-do list for awhile.

I've long intended to add a filter mechanism that would allow you to use file globbing and/or regex to exclude items. But it's such a geeky power-user feature that I keep putting it off.

Since you asked, I'll give it a +1.

2. The current explanation for the option "Ignore new events for ___ (min./hours/days/weeks)" &helips;

There are two issues here. First, I haven't updated the help for the new 2.0 features yet, so the behavior of the "Ignore" period for the new "Capture Items Changed" event hasn't been documented yet.

Second, the terminology is a little off because the "changed items" event are stateless and the whole events schedule mechanism is designed around stateful events, like mounting and unmounting a volume, logging in and out, or launching and quitting an application. Said another way, when a folder's content changes (the event) it stays changed forever (until captured). When an application launches, that launch event ceases to exist when the application quits again.

Because of these differences, how events and event state are treated during the "Ignore" period of event schedule is?as you've discovered?quit different for change events vs. stateful events.

The two need different terminology, and I plan to give them different interfaces, but that's probably going to have to wait until 2.1 when the UI gets an overhaul.