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

For the record, the value wasn't being set in the archive. The dialog was simply failing to reset the edit field with the old value before presenting it again.

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 can't do much about this, as this is OS X's auto-complete / spelling / whatever interface.

I have fixed the code so that non-numeric values will present a standard validation dialog, and you'll get the choice of editing it or reverting to the original value.

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.

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: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: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!

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

No big deal, but if you do install the next version and it crashes, send a diagnostic repot (Help > Send Report). The report will include any QRecall crash logs, which would also be helpful.

Ming-Li Wang,

Thanks for taking the time to beta test QRecall. You certainly get points for persistence.

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

Fixed.

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.

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

The QRecall Capture Preferences service was there, finally, though I had to enable it manually in System Services Configuration.

That, unfortunately, is now standard for OS X. New services are disabled by default; you must explicitly tell OS X which services you want to use.

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.

Sorry about that. When I went to check this out, I even found a note in the code: "TODO: Handle xattr set failure here." Obviously, I hadn't gotten back to that.

Anyway, I went ahead and implemented a warning dialog that will now pop up if QRecall can't set the capture preferences for an item.

It was never my intent to allow the QRecall service to set the capture preferences for items not owned by the user, although it's theoretically possible to do via an authorization request, and I'll add that to the wish-list.

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.

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

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.

I'm afraid it's going to be confusing either way.

Essentially, the "exclude item" setting is QRecall's version of OS X's "exclude item from backup" attribute, designed principally for Time Machine. When you configure your archive, you can choose to honor or ignore OS X's "do not backup" flag, and you choose to honor or ignore QRecall's "exclude item" setting.

So, basically, you have two ways of marking items to be excluded from a capture (OS X's and QRecall's) and you have the choice of excluding those items from the capture, or ignoring the settings and capturing either, or both, sets.

I'll try to make this clearer when I get around to updating the help. And I might change the name of the "Exclude from all archives" setting to something like "Setting cannot be ignored," or something like that.

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.

If it was easy, I'd do it myself. (Probably the most frustrating part of QRecall development is not being able to use QRecall all the time.) The main problem is that QRecall installs system services that are identified by name, and only one service with that name can be running. And for security, QRecall insists that all installed components must be the same version. This makes it an all-or-nothing deal.

Thanks for the great work. V2 does look promising.

Thanks. I look forward to you trying it again soon. The next (b10) release should include the fixes I mentioned here.

Steve,

I would expect the update from 2.0.0b8 to 2.0.0b9 to fail, as b8 has the flawed update code in it. The real test will be if the update from 2.0.0b9 to whatever version follows is successful.

I know I've got my fingers crossed...

Dear beta testers,

If you have encountered a situation where QRecall says that it's "Waiting for archive" when there's no obvious reason why it should, please send a diagnostic report.

Also note that if the archive isn't actually busy, the "waiting" situation should resolve itself after a few minutes. If it doesn't fix itself after ten minutes, definitely send a diagnostic report.

Adrian Chapman wrote:Maybe I'm not understanding something here.

All you have to understand is that these are probably bugs.

Also, is it my imagination but QRecall 2 seems MUCH faster at capturing and opening archives.

I hope so. A lot of time was spent benchmarking the Foundation and BSD APIs to get the best possible filesystem performance, particularly when reading all of the various file attributes needed to perform a capture.

Adrian,

We received your diagnostic reports. Were you experiencing any other problems, beyond what you've already reported, prior to reinstalling?

Steve,

Yes, this is a known issue (as was noted in the release notes ).

If QRecall encounters an error while trying to update itself:

Download the latest beta from http://www.qrecall.com/download/

Open the disk image

Run the Install QRecall application

But thanks for the console log anyway. We're still trying to figure out why Sparkle—which has always been a remarkably reliable piece of software—is failing.

See this post: http://forums.qrecall.com/posts/list/515.page

Thanks to everyone who's been brave enough to download the new version of QRecall.

It's been a bit of a rough start.

I've found and fixed a couple of bugs in the QRecall Monitor process that were causing it to freeze up (deadlock). This was related to status information for archives that weren't reachable. This has a domino effect, because any other process (the QRecall app, the scheduler, the QRecall service, ...) that tried to communicate with the monitor would then lock up too.

I have also been trying to resolve the problem with the auto-update feature, but I might not have a solution for that today. If I don't, I'll build a new beta, release it tonight, and continue working on auto-update at later time.

Adrian Chapman wrote:I understand that version 2 changes version 1 archives irreversibly, but can version 2 still be used to verify, merge and compact version 1 archives and leave them compatible with version 1.

Verify or recall, yes. Merge or compact, no.

Any action that changes the contents of an archive using QRecall 2.0 will write modern data structures, making the archive incompatible with earlier versions.

I ask because while I want to assist with testing the V2 beta on my iMac I wish to continue running V1 for now on my wife's Macbook but I run a weekly verify/merge/compact on her archives from my iMac.

To preserve 1.x compatibility, you'd need to schedule the merge actions to run on the Macbook. You could also schedule it to perform the compact, but for the short term of the beta test cycle you might just consider not compacting the archive. You can continue to verify the archive from the iMac with QRecall 2.0.