Jeffery,

Sorry to hear you're having problems.

Thank you for sending a diagnostic report. This helps immensely.

It appears from your report that you have relocated your home folder to a different volume. This greatly complicates the QRecall installation. Privileged executable, system daemons, XPC services, and some user agents must reside on the startup volume. For security reasons, macOS won't launch some executables if they reside on a non-startup volume.

To work around this limitation, QRecall relocates some of its components to a special system directory when the user's home folder is not on the startup volume. Specifically, it creates this path:

/Library/Application Support/QRecall/504

where "504" is the UID of the user installing QRecall.

Somehow, your installation has gone sidewise because this directory has the wrong owner:

ls -l /Library/Application Support/QRecall
drwx------  6 505  80    192 Mar 17 19:47 504
-rwxr-xr-x  1 0    0   19152 May 12  2018 QRecallKickStart

ls: /Library/Application Support/QRecall/504: Permission denied

The "504" directory is owned by user 505, not 504, and QRecall (running as user 504) can't see or modify the components in this directory. So the installer steps fail, and anything that is installed there won't launch.

The other problem logged is "Failed to install Privilege Elevation service", which indicates you have a mis-installed privileged helper. This sometimes happens in macOS, where you go to install a privileged service, macOS prompts for administrator's authorization, and then something goes wrong. The helper doesn't get installed, but macOS won't prompt to replace it, and you're stuck with a non-functional installation.

To rectify both of these, I would suggest the following:

Delete these paths:

/Library/LaunchDaemons/com.qrecall.hoist.plist
/Library/PrivilegedHelperTools/com.qrecall.hoist
/Library/Application Support/QRecall/504

Restart your system

Launch QRecall and let it reinstall itself again

This will eliminate the mis-installed support folder for user 504 and manually un-install the privileged helper.

Please send a diagnostic report afterwards so I can verify the correct installation (and look for possible QRecall bugs in how your situation was handled).

Bruce Giles wrote:I did get QRecall 3 beta 78 running on my Mac at work.

Bruce,

I'm assuming you didn't see my email about your earlier problems. I included a link to a pre-release build of QRecall 3.0b79 for you to try. I was particularly interested in how 3.0b79 dealt with your 2.x archives. I expect 3.0b78 to have the same problem(s) as 3.0b76, in that regard.

I'll send the email again (for the details), but you can download the pre-release 3.0b79 and try it. I was hoping on evaluating this change to include, or exclude, it from the next release.

In the mean time, I'll review the diagnostic reports you just sent.

Promises of an iCloud Drive compatible stack container were premature.

Over the past few weeks, we've encountered some technical difficulties in reliably using iCloud Drive as a stack container. We are committed to getting this to work, but it will take some more time.

We've tested the existing Document stack in Dropbox and Google Drive and it appears to be working just fine.

For Dropbox:

Install the Dropbox extension.

In Dropbox ? Preferences ? Sync, turn on Smart Sync (Save hard drive space automatically).

Create a Document stack container and store it anywhere in the Dropbox location.

For Google Drive:

Install the Google Drive extension.

In Google Drive ? Preferences ? Google Drive, turn on Stream Files.

Create a Document stack container and store it anywhere on the Google Drive volume.

These are not ideal solutions, but they work. We will probably develop Dropbox and Google Drive specific containers, but that's further down the to-do list.

Bruce, that is quite the story of woe! Sorry to hear you're having such a rough time.

First, please send a diagnostic report. I'm particularly interested in your crash logs, because you're getting a lot of crashes for some reason (both versions!) and I think we should start there.

M Wang wrote:Reading this gives me hope that maybe Google Drive or OneDrive will be supported someday?

QRecall stacks might be compatible with Google Drive or OneDrive already, I just haven't tested those yet.

Basically, QRecall stacks should work on any cloud drive service that (1) automatically uploads items stored on the local "drive" to the cloud, (2) replaces the local copy with a placeholder, and (3) transparently downloads the original item again whenever that file is accessed.

Most cloud drives work this way.

The problem with iCloud (which may, or may not, be an issue with Google or OneDrive?again, haven't tested them yet) is that iCloud treats the entire stack container as a single document. So simply trying to check the status of the stack container document ends up re-downloading all of its individual parts, which completely defeats the purpose of using a cloud document.

The next update to QRecall 3 will address this.

I have been running v3 betas on my system for a few months without issues, but have yet to try the "stacks" feature, mainly because it seems to be something useful only for backing up to the cloud. Am I right? Or is it something worth doing even when backing up locally?

Stack document can also be used for local redundancy. Specifically, a lot of users capture their documents to an archive. They then either sync or copy that archive to a second drive which is taken off-site, or they rotate between a set of archives (at least one of which is always off-site).

Stacks can simplify this off-site drive rotation, and is much more efficient at doing so.

Pierre,

Thanks for the diagnostic report. There's defiantly a bug here, as the log reports that there are aliases to old archives and QRecall is deleting them ... but they never get deleted. I'll add this to the bug list.

Did manually deleting the alias files in ~/Library/Preferences/QRecall/Recent Captures folder solve your problem?

Pierre,

Sorry for the inconvenience.

This message occurs when a capture updates the list of recently captured archives, but finds a broken link to an archive that's been deleted or moved. It should only happen once.

Start by sending a diagnostic report (in the QRecall app, choose Help > Send Report). There might be some clue as to why the link to your old archive isn't getting automatically removed.

To stop this message, open your (home folder)/Library/Preferences/QRecall/Recent Captures folder. Select of the files in that folder and trash them. New links will be automatically recreated the next time each archive is captured.

These links are actually only used for the Reveal in Archive service, so unless you use that feature before the next capture you won't notice anything different.

Finally, you might also have archive status information too. In the QRecall app, choose Window > Status. Right click on the obsolete archive and choose "Forget". Alternatively, you can just wait; obsolete status information is discarded automatically after 7 weeks of inactivity.

Steven J wrote:1. Any plans to allow iCloud to be an stack destination? i.e., create an stack container on iCloud Drive ?

That should be possible within the next couple of weeks.

2. Does the beta respect file attributes set on an individual file/folder from version 2 via the Services menu?

Capture preferences have not changed, and both versions 2 and 3 support the same set of options.

3. Can the Beta run along with version 2, or does version 2 need to be removed in order to test the beta? (I notice many of the component names are the same).

Sadly, no. Two versions of QRecall cannot coexist. An archive you use with version 3 will be upgraded and will not be backwards compatible with version 2. If you save the original archive, you reserve the option of uninstalling version 3 and reinstalling version 2.

4. Can the archive destination be either HFS or APFS? Any advantage using one over the other?

There are some advantages to using APFS volumes for your archive. QRecall now takes advantage of file cloning, so actions like capture start and finish faster, and there's less chance the archive can get left in a state that requires it to be repaired. The disadvantage is that APFS volumes tend to get more fragmented (hurting performance), which is something we're working to address.

Steven M. Alper wrote:But my point is that I don't think QRecall should ever cause a disk to unexpectedly eject, no matter what's going on.

That's an excellent point, and I can assure you QRecall would never do such a thing. In fact, QRecall can't do such a thing even if it wanted to?and it would never want to.

The most an application can/should do is request that a volume be unmounted. QRecall only does this for actions on external volumes following the successful execution of an action. It makes no such requests at any other time.

Furthermore, this is a request, not a command. The filesystem is the entity that unmounts a volume, and will only do so after all files on that volume have been closed. So any open files (and repair will have multiple files open until its done) will prevent any software from unmounting the volume[1].

Finally, there's no way to unmount a volume (unless the drive can be physically ejected) in such a way that it can't be remounted again.

My conclusion: there's something wrong with that volume/drive. I'd defiantly perform a volume repair to look for structural damage (which is more likely the fuller a volume gets). But the fact that the volume can't be mounted again makes me suspect hardware issues, which are often bus related. Try switching communication paths (i.e. switch from FireWire to USB), or change drive enclosures, if you have that option.

Steven M. Alper wrote:I will probably move one of the damaged archives to another drive and see if I can repair it there ...

This is the most sensible approach.

An alternative, which is also an experiment, would be to use QRecall's "Recover" mode when doing the repair. This mode only reads data from the source volume, and writes the reconstructed archive to a different volume. The reconstructed archive will have no empty space, although it's possible that it could be made smaller still by compacting again. This is much faster than copying an entire archive and then repairing the copy, because the repair and copy happen in a single pass.

The experiment is that if the volume spontaneously ejects simply while being read, there's definitely a hardware problem here.

[1] There is a "force eject" function in the OS that can force a volume to eject with open files. QRecall certainly never calls this, but some other software might. But it's far more likely volume structure corruption or hardware is the cause.

Greetings,

I assume you're talking about the Run menu in the QRecall Monitor's menu bar icon and/or dock icon.

That list is built from the actions you have defined. If you're seeing actions that are no longer relevant, simply delete them.

Open the Actions window (Window > Actions) and do whatever housekeeping you deem appropriate.

Ming-Li Wang wrote:One minor suggestion, if I may: please consider adding a set of "Save/Cancel" buttons to the action settings dialog. Having to close the window before being offered an opportunity to save the settings feel odd.

An action document window, which you get if you open the action from the Actions window or by choosing "Edit in Separate Window", is a standard macOS document window. Changes aren't saved until you choose File > Save, or try to close the window without first saving it.

QRecall's UI became a little more complicated (read "inconsistent") when action documents were added to the sidebar in the archive window. Since the "Save" command doesn't apply to an archive document, and the sidebar can show multiple action documents at once, the "hack" was to add individual "Save" and "Revert" buttons to the sidebar interface?equivalent to the standard File > Save and File > Revert commands.

So while I appreciate the confusion, I'm reluctant to add yet another layer of non-standard window behavior when the action is being edited in its own window.

Sorry to hear you're having problems with the beta.

The first thing to try is to open the action and remove, and then re-add, all of the items to capture. Then save the action and see if that helps.

The location of the items to capture are stored as bookmarks, and it's possible those they were out-of-date. Removing and re-adding them will create new bookmarks.

Also, send a diagnostic report. (Open the QRecall application and choose Help > Send Report). This will upload your recent log records so we can examine them. These records contain a lot of low-level details about the scheduler and change events.

If the system won't bless the volume, it means the operating system is cryptographically signed and you'll have to reinstall the OS on top of your restored volume to make it bootable again.

"Security is the opposite of convenience." -- unknown

That message means that QRecall couldn't "bless" the startup volume for you. It just means you'll have to do it manually using the Startup Disk system preferences pane.

Mike,

The "Lifeboat" volume is just a temporary volume used to as a springboard for recovering your system. You use recovery mode to create the temporary volume and install a bootable OS. This OS is not the OS you will eventually install or recover, and doesn't need to be the same version.

The volume you eventually recover will be some other volume, either your original startup volume, or a new volume that you create and restore to.

If you don't see an option to reformat the entire drive, repartition, or add a new volume, then you need to switch Disk Utility's view mode to "Show All Devices." In the simpler "Show Only Volumes" mode it only lists logical volumes that have already been created. The "Show All Devices" mode shows the logical tree of hardware, partitions, containers, and logical volumes.