If one make a change to the number for the "Keep deleted items for at least ___ [unit]" setting in the archive settings window, then click the "Cancel" button to dismiss the window, the old value would not be retained as expected. Instead, the new value would be kept.

When the Archive Settings window is opened, in addition, the focus (cursor) rests in the number box with the whole number highlighted. If one hits the ESC key at this time (in an attempt to cancel the dialog), the number would be replaced with the letter "I". Hitting ESC again would change it back to the old value, but clicking outside the box would make the "I" stick and get an error message about invalid number.

I've since managed to reproduce the problem with different archives and on different disks/partitions. I'll email you a test archive that crashes QR when compacted (at least on my system, every time) in a minute.

Ming-Li Wang wrote:6. I can't disable the "Cache Files" standard exclusion for one of my archives. I've unchecked the item and saved, many times over, but it always remains checked the next time I open the archive settings window. Very weird, for there is no such problem for other archives.

I spoke too soon on this one. It seems the choices made about standard exclusion options on the "Archive" - "Settings" page don't always stick.

For example, if an archive has all but "Cache Files" checked, then you uncheck the "Items Excluded by Time Machine", the choice would be undone once you close the archive.

I made a 30-sec. screencast (.mov file) to show you exactly this. In the video, I

1. opened an archive named docu, opened the Archive Settings window (with the keyboard shortcut), and unchecked "Items Excluded by Time Machine",

2. opened the Settings window right away, and as you can see, the "Items Excluded by Time Machine" is disabled,

3. close the archive,

4. open the archive again, and

5. open the Settings window again.

Voila, now you can see for yourself that the "Items Excluded by Time Machine" option has been reverted back to enabled state.

I can't find any pattern yet except:

1. Clearing all options (disabling all) always sticks.

2. Enabling any combination of options (that I've tried) when none was checked (i.e., after taking the previous step) always sticks, too.

Perhaps I should add: the archive was created by v1 a few months back, and is updated often. Since I switched to v2 yesterday, 9 layers have been added. Redundancy has been enabled, too.

I made a backup copy of the archive before going v2, which can be compacted without issue.

Got "internal program error" midway through a compact action. The Log shows "unexpected buffer contents" messages. Report filed.

Couldn't open the archive afterward; had to repair it first. Verified the volume first and ran into incorrect file hard links numbers (or something like that) error. The disk was repaired successfully and then so was the archive.

Tried to compact again, and ran into the same error again, only this time disk verification turned up no error and the archive was successfully repaired.

Tried to compact other archive and haven't run into similar trouble so far. Could be something wrong with the disk, or the archive.

James Bucanek wrote:That's what I see too. But the OS X crash logs are remarkably uninformative in this case, so I can't tell exactly where/why it's crashing. If you have copies of those old (pre-upgrade) action documents, could you please email them to support@qrecall.com?

Done.

Actually it's modifying a whole bunch of things. And I don't put everything in the release notes; they're long enough as it is.

Understood. Your release notes are indeed very informative. Thank you.

One of the things that gets updated for every action are the alias records.

I didn't know anything about "alias" in QR, and therefore have never used it intentionally. Is it the same thing as Finder alias?

Some more observations and thoughts:

1. The "+" and "-" buttons for customized exclusions are indeed working now, thanks!

2. The "qrecall" command line is very useful. I can now set up all my permanent exclusions in a bash script. Wonderful.

3. I turned on redundancy for a few archives. The warning (that this is a time consuming task) looked scary, but it turned out to be much faster than expected. It took merely 19 sec. to add redundancy to smallest archive (6+ GB, with many small files) on an SSD. A much larger archive (60+GB) on an slow WD Green HD took 18 min., and my largest archive (350+GB, on the same HD) took barely over 1 & a half hours (all using the 1:8 ratio). Impressive.

4. b10 seems pretty stable, but this morning (about 9am, Taiwan time) I found the Monitor window on the desktop, listing the verification for an archive as the next action, but the scheduled time for that action was 4:40 am. QR was very sluggish. The rainbow wheel spinned for a few sec. with each move (clicking on the menu icon, clicking a menu item, etc.). Restarting the Monitor didn't help. I had to kill all QR processes in the Activity Monitor. The log shows a lot of "Unable to communicate with helper" warning since 4:10 this morning.

Btw, I couldn't get QR scheduler to restart after having it killed in Activity Monitor (relaunching QR didn't restart the scheduler).

5. Starting an action manually in the "Actions" window doesn't start it immediately. See the attached screenshot--next action at 11:39, system time at 11:43--for an example. The action was finally executed at 11:45, which was the nearest time for a scheduled action (for another archive). It's the same when I tried to execute another action (a Verify action) manually.

6. I can't disable the "Cache Files" standard exclusion for one of my archives. I've unchecked the item and saved, many times over, but it always remains checked the next time I open the archive settings window. Very weird, for there is no such problem for other archives.

7. Speaking of cache files (and items excluded by Time Machine), v2 has retained the same behavior from v1 of excluding the whole "Caches" folder (not just its contents). Would you consider changing it to something equivalent to the new "contents exclusion" mode? Time Machine's standard exclusion plist specifically says some folders should be retained (while their contents are discarded), and my experience was the system would behave abnormally if some of the folders were not there after restoring from a backup.

8. When trying to check my QRecall Capture Preferences settings with the "qrecall captureprefs list -r -s ~/Documents/" command, I got the following error message:

2015-08-02 12:07:28.975 qrecall[8920:60370] *** Assertion failure in char *DDNewCPath(const char *, const char *)(), /Users/james/Development/Projects/Quantum Recall/Common/Source/Filesystem/DDPath.m:696
* parent path (/Users/wang/Documents/) ends in '/'

Removing the trailing slash solved the problem, but you might want to add some fault tolerance codes or tweak the error message a little to make it less scary.

That's all for now. Thanks for listening.

OK, more interesting findings.

1. Before I rebooted (for the first time after b10 installation), I moved all the actions back into the "Actions" folder, and tried to open QR again. Voila! It opened without problem. Open the Actions window and I could see all the actions. No conversion was done.

I rebooted and reinstalled b10 again, with my old Actions folder in place, and QR launched without problem after installation, but again no conversion was performed. I thinks it's because the 2nd installation checked and realized v2 has been installed before, and skipped the conversion step.

I've since done more tests, and can confirms that v2 would crash on my system after installation when upgrading from v1 to v2, unless I empty the "Actions" folder beforehand.

What I don't get is: v2, on first run, should only try to convert customized exclusions into QRecall Capture Preferences, according to the release notes. If that's the case, only capture actions should matter. And yet, as stated in my previous report (see step 2 in the previous post), removing all "capture" actions from the Actions folder didn't prevent QR from crashing after installation. Only removing all actions worked.

2. On the missing QRecall Capture Preferences service, I've found that it (along with 2 other services for "Files and Folders") would be installed only when v2 is installed after every files and folders related to QRecall has been removed before installation. Before doing that, I tried removing all the plist files inside ~/Library/Preferences, the QRecall folder in the same folder, and all plist files inside the various LaunchDaemon/LaunchAgent folders on the system, and still couldn't get those services installed.

That's all for now. Off to play with the new beta (thank you for the speedy release).

Installed beta 10 just now and it crashed right after upgrade, same as my experience with b9.

Since I knew it had something to do with defined actions, I tried the following in order:

1. removing 2 of the capture actions I considered to be most likely offenders since they have many exclusions defined, some of which don't exist on the system at the moment.

2. removing all capture actions.

3. removing all actions from the "Actions" folder.

QR finally launched without issue after the 3rd step. A diagnostic repot was then sent immediately.

Oh, I also checked and could not find the QRecall Capture Preferences service.

I'm going to reboot my system and see if that makes any difference.

It would appear that your initial install of QRecall 2.0 failed spectacularly. If you still have the QRecall.log for that time period, please forward it to support@qrecall.com. (You'll want to compress it first, as it can often be rather large.)

That's my guess as well, but I reinstalled several times, and tried my best to do it as cleanly as possible. A little more detail:

I've kept the habit from my Windows days of keeping a detailed system setup diary when setting up a new system--a plaintext file recording all the tweaks and software installations in the order they take place, along with software license codes and other notes. The installation process is organized in stages, with a fresh new system with nothing but the most basic, essential tweaks made and no software installed as stage A0, and it moves from there to A1, A2, A3 ... and so on. At the end of each stage, a system image (.dmg file) is made (by booting into the rescue partition or a live USB drive I keep for this purpose).

This way, I could revert the system back to an earlier stage if something goes wrong in a later stage. Some of those .dmg files are eventually discarded to save space when the system seems to be running without issue, but some are kept so that I can try new software at will.

When I first installed QR 2.0 beta 9, I did it on my then current, running system. When QR crashed after launch, I suspected failed installation because QR 1 was running at the time. I then tried to quit all QR processes in Activity Monitor, but one process was very persistent. I then booted into my live USB drive, removed all QR launchers in the various LaunchDaemon/LaunchAgents folders, and booted back into the system without QR running. Reinstalled beta 9 and it still crashed.

I then reverted the system back to A3, A2 and finally A0 (disk image for A1 has been discarded). Because QR v1 was installed in stage A1, A3 & A2 got the same treatment after restoration so they booted without QR running. And yet beta 9 crashed right after installation as well. And the QRecall Capture Preferences service was never installed. The only time I could install b9 without issue was when the system was reverted back to the bare minimum A0.

Sorry, no logs were kept, but I'm pretty sure the problem is reproducible on my system. If it happens again with b10 (if I have time to try it), I'll keep the log.

To set the capture preferences for an item you don't own, use the sudo and qrecall command line tools:

sudo qrecall captureprefs exclude /Path/to/excluded/item

Great. Thanks.

If it was easy, I'd do it myself.

OK. I'll see if I can run my saved systems in a VM (Virtualbox).

I have been using v1.2.3 for months and decided to try out 2.0 beta for the first time. Grabbed the b9 dmg and right after installation QR crashed. Rebooting didn't help. (Yes, all my archives are online and reachable.)

After hours of trials and errors, QR finally opened after the "Actions" folder under ~/Library/Preferences/QRecall had been emptied. As a result, QR did not convert excluded items defined in my actions into QRecall Capture Preferences. I then tried to add them manually in the archive settings, only to find the "+" button broken. It did absolutely nothing when clicked.

Not to be detered, I tried to use drag-n-drop (from finder) instead, and was delighted to find that worked. The joy was shortlived, however, as I soon realized the "-" button was broken, too, and there was no way to remove an excluded item. Can't edit them out from the plist file either as they are now encoded therein.

Next I tried to use the new QRecall Capture Preferences service, only to find it nowhere to be found, not even in System Services Configuration (the one at "System Preferences - Keyboard - Shortcuts - Services"). Reinstalling didn't help.

I finally took the drastic step of reverting my system back to a stage before QRecall was installed, and installed v2 beta 9 without installing v1.2.3 first. The QRecall Capture Preferences service was there, finally, though I had to enable it manually in System Services Configuration.

Time to test it out. I set several folders on my system partition to "Do not capture contents" with the "Exclude from all archives" option enabled, and then back it up to a new archive. It went smoothly, but several excluded folders were still backed up despite the setting. I soon realized the extended attribute wasn't really set because those were privileged folders (owned by root). QR really should ask for permission to set the XA, or at least give a warning about not being able to set the XA. It did neither.

I gave up at this point as my leisure time was up. I'll try again later.

A few suggestions:

1. The ability to save a folder without capturing its content has been one of my most wanted features. Restoring the system partition with QR has been a pain without this feature as I always have to spend much time recreating the excluded system folders with the right ownership and permissions.

The new QRecall Capture Preferences service is thus a great addition, but it needs to be able to work on privileged folders, and I hope the same functionality can be extended to per-archive exclusions.

2. The "Exclude from all archives" option is confusing. I first thought it meant excluding from all archives instead of just this archive, only to realize soon that this is not a per-archive exclusion, so the "Do not capture" setting can't be archive specific. I had to dig out the release notes to know its true meaning. I would suggest something like "Override archive setting" instead.

3. I don't know how difficult this is, but I truely hope there is a way for v1 and v2 betas to co-exist on a system, so I could try out the betas without messing with existing archives and backup routines.

Thanks for the great work. V2 does look promising.

Good to know. I remember seeing the "severity slider" in the help documentation, but have forgotten about it until you mentioned it. A clever and very useful design, indeed. Thanks.

Diag. report has been sent as requested.

Thanks for the tip about the log. I "discovered" it only yesterday. (I probably saw it when checking out the menus in the beginning, but have never used it. I'm used to hunting for logs in the various usual places, so the user friendly design of QRecall log didn't registered. Sorry.)

Speaking of log, I found several peculiar entries that may (or may not) have something to do with the mystery. It's an error message that says "Unable to connect with helper". There are several occurrences in the log, including a recent one at 10:35:21 local time (it's 11:05 right now).

There was one action scheduled around that time, at 10:35 sharp (a "Capture" to a different archive), and there's no log entry of the action (before or after the error), but I'm pretty sure no change was done to the associated source folder, so there's nothing to capture.

Going further back, another "Unable to connect with helper" error was logged at 00:29:22 today, but no action was scheduled then, I believe.

Because the first crash happened when I tried to compact the archive after deleting the newest layer, I decided to try it again, this time on a clone of the archive. Here's what I found:

Action -- result
1. delete the newest layer -- QRecall crashed
2. reopen the archive -- no problem, and I can see the layer is indeed gone
3. verify -- no problem
4. manual recapture of the whole volume -- no problem
5. deleted the newest layer again (the one created by manual recapture) -- no problem
6. verify again -- no problem
7. compact -- NO PROBLEM!


To see if this is a fluke, I deleted the clone, made a new clone from the original archive and tried the following on the original:

Action -- result
1. verify -- ok
2. compact -- QRecall crashed
3. reopen QRecall -- no problem, but there's no entry of the last action (compact) in the log (the one accessible from the "Window" menu)
4. reopen the archive -- no problem
5. delete the newest layer (scheduled capture earlier this morning) -- NO PROBLEM
6. compact again -- NO PROBLEM

The compacting recovered almost 600MB of space after 3+ min., while the layer deleted just now took only 19 MB of space and there's no other layer merged or removed before today. If the compacting that caused the first crash (the one on 2/2) succeeded as you said, it probably didn't "finish" the job, for

1. the successful compacting just now should not be able to recover this much space if the earlier one did its job, and
2. QRecall crashed less than 2 seconds into the action then, but the successful one just now lasted 3+ minutes.

Anyway, the problem seems to have gone away. I'll keep an eye on this archive and report back if I run into any other issue.

No, I've opened the archive many times afterward, and scheduled daily captures have been going just fine since. Verifications (scheduled and manual alike) have never reported any error. And yet every time I try to compact that archive, QRecall crashes. Compacting other archives is never an issue, and I compacted this particular archive successfully before.

Done.

Could you please tell me (or is it documented somewhere) exactly what is sent with the "Help - Send Report" function. The QRecall*.plist files in ~/Library/Application Support/CrashReporter, and the QRecall*.diag files in /Library/Logs/DiagnosticReports, I gather. Anything else?

Thanks.