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.

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).

Ming-Li Wang wrote: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.

Correct. QRecall sets the QRUpgradeLevel preference once it has finished performing the (rather expensive) v1.x to v2.x update. If you ever want QRecall to perform this update again, use this terminal command:

defaults delete com.qrecall.client QRUpgradeLevel

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.

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?

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.

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.

One of the things that gets updated for every action are the alias records. When upgrading to 2.0, QRecall tries to convert every legacy alias record into a modern URL bookmark structure. I say "try," because the item the alias refers to has to be reachable for the conversion to be successful. Any items that aren't reachable are left as legacy alias records (which QRecall 2.0 can still use).

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

Keep us posted!

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.

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.

Ming-Li Wang wrote: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.

If something like this happens in the future, please send a diagnostic report before killing any of the processes. The Send Report command in QRecall 2.0 now samples all of the running QRecall processes to see what they were doing at the time, but if you kill them first that information is lost.

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

Please send a diagnostic report. There might be a clue as to why the scheduler didn't restart.

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.

I discovered this about an hour after I released b10. The change to the scheduler that stopped it from running all the time has gone too far in the other direction, and now it doesn't check the scheduler often enough. *sigh* This should be fixed in b11.

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 can't reproduce this, but I recently fixed another bug with how filter definitions are stored in the archive document which might explain why this is happening. Try it again when b11 is released.

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.

Testing has shown that all of the "well known" folders in /Library, ~, and ~/Library (like the Caches folder) will automatically be recreated as needed. Most of the excluded folders that must be preserved are the core BSD folders (like /dev and /private/var/vm). If those folders don't exist, the system won't boot.

Of the folders that are automatically recreated, I'm inclined to leave the behavior as it is on the theory that it's likely to cause less problems since the folder will be lazily created with the correct ownership and permissions. The only exceptional case would be if you've set some special ownership, permissions, extended attributes, or Access Control Lists on the folder and want those preserved. If that's the case, turn off the "a la carte" exclusion setting in the archive and use the capture preferences to exclude just the contents of those folders.

When I have a chance, I'll look into how difficult it would be to exclude just the contents of the "a la carte" excluded folders.

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.

Error messages are supposed to be scary.

This was just a bug, now fixed. The captureprefs subcommand was failing to sanitize its path arguments.

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

I'm pretty sure this is fixed in b11.

I think the basic bug, which is why it was so confusing, was the inability of the archive to determine when the settings had actually changed. (Settings are only rewritten to disk when they change.) Some combinations would trigger a save, others wouldn't...

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

Yes, they're the same thing. The alias files created by the Finder are just alias records written to disk. OS X provides a number of semi-opaque data structures for remembering where a document has been stored. The alias records were a carry-over from Carbon (OS 9), so that gives you some idea of how old they are. The URL Bookmark structure performs the same task for modern software.

Anyway, I was able to reproduce and fix all of the alias->bookmark conversion problems you found in b10.

James Bucanek wrote:

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

Please send a diagnostic report. There might be a clue as to why the scheduler didn't restart.

Done. I force quit both the scheduler and the monitor in the Activity Monitor right after a reboot. The QR monitor recovered in less than a sec., but the scheduler didn't. Opening QR didn't help, had to log out and log in again to get the scheduler back.

Ming-Li Wang wrote: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.

It looks like you're getting your wish, after all.

To be compatible with OS X 10.11 (El Capitan), the filtering of most system folders (trash, cache, /dev, mountpoints, and so on) has changed. QRecall 2.0.0b15 now captures those directories, but excludes their content.

With El Capitan's new System Integrity Protection features, many of these directories are protected and have very specific permissions and file flags. Starting with OS X 10.11, if any of them are missing or have the wrong permissions, the system won't boot.

Yeah, I saw it in the release notes. Thank you!

It seems v2 is almost ready. I have had no bug to report for weeks.