David Ramsey wrote:* restore process failed: folder not found in selected layers

Hmm, it works here for me...

Basically, the command is saying that /Users/dramsey/Library/Preferences/QRecall/Actions doesn't exist in the latest layer. Are you also sure you only have a single volume and owner? Is /Users/dramsey on a different filesystem?

What happens if you try this:
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences/QRecall/Actions'

You can try shorter versions of this (i.e. qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users') to try and narrow down where the missing piece is.

Lazy is good. Getting computers to do our work for us is how we got this far

You can use the qrecall command tool, which can be added to a Terminal/shell script, executed from an AppleScript, or about a thousand other ways.

qrecall restore <path_to_archive> '*:*/Users/<you>/Library/Preferences/QRecall/Actions'

Note: the shorthand syntax '*:*' (or just ':') works when you have only one owner with one volume in the archive. If you have more than one, of either, you'll need to see man qrecall section on <item> syntax for details about specifying the owner and volume you want to restore from.

David Ramsey wrote:It has the minor drawback of needing to recreate the actions if I ever restore from the backup volume, ...

But those action documents would still be captured in your QRecall archive, so you could just restore them from that backup.

David,

Interesting problem.

QRecall uses "bookmarks" (the modern macOS replacement for aliases), and you are correct; if you create a bookmark of your startup volume, or an item on that startup volume, and later resolve that bookmark when booted from a different startup volume, it will find that item (first) relative to your new startup volume, not the original volume (even if it's online).

I believe you can exclude items from your CCC Backup. So the simplest solution would be to exclude the contents of the ~/Library/Preferences/QRecall/Actions folder. Then when you boot from your external drive, QRecall won't have any actions to run. (And don't forget to delete any old actions on your CCC Backup volume.)

Sorry for the delay in addressing this; it took a little time to reproduce exactly what was happening.

I'm pretty sure this pre-release version will fix it: QRecall 2.1.14(3)

Same drill as before: install 2.1.14(3) and let it run overnight.

David,

Thanks for sending a diagnostic report. It was just want I needed to determine ...

... QRecall is totally at fault!



So here's what's happening,

You have a capture action set to run at 3:00 each day. That action has a condition that holds the action until the archive volume is attached. So the scheduler starts the action at 3:00 (something that shouldn't be happening because Apple's power nap is not supposed to run third-party software when your laptop is closed, but that's another story), but then immediately places the action on hold.

Now here's what's going wrong. We recently made a change to the scheduler so that it prevents your system from going into idle sleep because a few users were having an issue with actions starting at the same time the computer wanted to go to sleep; the action would start, connect to a file server, then immediately go to sleep, which would result in network errors when the computer woke up again.

In your situation, however, this is a disaster. Once your action starts, the scheduler is now preventing the system from going to sleep since actions are "running." But your capture action isn't really running yet because it's held by a condition. So the laptop stays awake until the battery is dead.

I think I've fixed this and you can try this pre-release of QRecall version 2.1.14: This version only treats actions that have started but are NOT being held as "running", for the purposes of determining if the system should be allowed to go to sleep. If you do try this version, let it run for a few days and then send another diagnostic report.

Another solution that would work with the current version is to remove the "hold while no archive" condition and change the schedule to an event schedule that runs the action when the "archive volume connects". Now, the action won't attempt to start until you connect your external drive. If you connect and disconnect your backup drive once a day, that's all you need to do. If you have occasion to leave the drive connected for more than a day, consider adding a "Repeat again" interval so that capture runs again the next day.

David Cretney wrote:Is it possible, likely, or impossible for QRecall to try to complete a back up while sleeping with the lid closed? Or, would it do that but abort if the disk is not found?

Unless you have "power nap" enabled, nothing at all runs when your laptop lid is closed.

And if the volume containing the archive isn't connected, no QRecall action will accomplish anything. Any action that did start would simply log an error that the archive could not be reached and stop?end of story.

David,

QRecall, like any software, uses energy while it's running and if your laptop isn't connected to A/C your battery will get used.

However, it shouldn't cause it to drain completely. In fact, if you used the capture assistant to create your capture action, QRecall will have added a "Stop if power remaining drops below 20%" condition to your capture action; this is designed to stop a running action once the battery gets too low. If you don't have that condition, consider adding it to your actions that run at night.

Another test is to simply skip all of your QRecall actions for a few, or alternate, nights and see if there's any difference. This can be done by choosing the Hold All Scheduled Until… command and selecting a time tomorrow.

If you want me to look into this further, please send a diagnostic report (Help > Send Report…). It will include a lot of details that aren't visible in the log window.

Thanks for the update. This definitely points us towards the problem.

The "Show when actions start" and "Hide when actions complete" shouldn't affect the dock settings, but we'll look into it.

Adrian,

We're not seeing that here, but let's isolate the problem to see if the problem is the monitor app or the interface that sets the preferences for the monitor. (My money is on the later.)

1. Perform a "quick" uninstall of QRecall (Holding down the Option and Shift keys, choose QRecall > Quit and Uninstall).

2. At this point you can, optionally, restart your system. This should work without a restart, but you never know. (In fact, it should work without steps 1 and 4, but settings preferences for other apps while those apps are running is no longer reliable.)

3. Open up Terminal and run the command

defaults write com.qrecall.monitor QRMonitorRegularAppMode -int 1

4. Launch QRecall again and re-authorize it

This should manually set the "always" mode for the monitor in the dock. Check to see if it's behaving that way (Monitor app appears in the dock when no QRecall actions are running.)

If this works, then the problem is somewhere in the preferences UI. After you set it this way, don't try to change it again using the preferences UI (until we get it fixed) as doing so will likely reset it again.

John,

That's weird. With actions selected in the Actions window, the only reason that menu item should be disabled is if none of the selected actions have a schedule.

Use man qrecall for the command-line syntax. But in brief, use the qrecall info actions command to get the list of actions, then qrecall (un)suspend <action> to suspend, or reactivate, an action's schedule.

Regardless, I would also request that you send a diagnostic report (Help > Send Report) so we can look for anything unusual.

John,

Make sure you have one or more (scheduled) actions selected in the Actions windows. (You can't suspend an action that says "Not Scheduled").

You also have the option of right/control+clicking on an action(s). There's also a command-line option, if you're so inclined.

John,

The QRecall scheduler, monitor, and actions run independently of the QRecall application. So it doesn't matter if the QRecall application is running or not, scheduled actions and actions you've started will run on their own.

The temporary solution, for situations like this, is to simply suspend all scheduled actions. You can do this from within the QRecall application (Action > Hold All Schedules > Until...), or use the same command in the QRecall Monitor (Hold All Schedules > Until...). Set a date and time that is after, or near, the date you plan to be back.

A more lasting, and targeted, solution is to disable the schedules of individual actions. Select one or more actions in the Actions window and check Action > Suspend Schedule.

When you return, you can simply wait for the hold time to expire or manually resume all schedules (Action gt; Resume All Schedules) if you used the first technique. If you suspended their schedules instead, uncheck the suspension (Action > Suspend Schedule) for each action.

See QRecall Help > Guide > Automation > Scheduling Actions

David,

QRecall already unmounts the volume containing the archive, but only if it wasn't mounted when the action started. QRecall automatically tries to mount the archive volume before the action starts. If the volume previously offline and is successfully mounted, it will also attempt to unmount it again when the action finishes. If the volume was already mounted, it does nothing before or after.

So one solution would simply be to leave the volume unmounted. QRecall will mount it before the 0300 action runs, and unmount it again when it's finished.

If that's not practical (because most external drive auto-mount when connected, or maybe you're just using it for other documents), there's another approach.

You could create an epilog script to unmount the archive volume at the end of the action. A bash script to accomplish this would look like this:

#!/bin/bash



diskutil unmount "${QR_ARCHIVE_VOLUME_MOUNTPOINT}"

QRecall provides the script with the mount point of the volume containing the archive; all this script does is pass that to the diskutil tool requesting that the volume be unmounted.

You can create this script in any plain ASCII text editor (I would suggest BBEdit, which is free to use). Save the file with 7-bit ASCII or UTF-8 encoding (no BOM) and name the file with a .sh extension. If you're not using a smart editor like BBEdit, you'll need to use the chmod a+x ... command to assign execution privileges to the script file.

Then go into capture action and add the script as the action's epilog.

Note: in all cases (this script, QRecall, dragging the volume to the trash), the volume will not be unmounted if other software has files open on it.

Nico,

That's an interesting idea, and certainly nothing I ever thought of.

I suppose it wouldn't be too difficult to implement, but it would take me awhile to consider its utility and an interface. I'll put it on the "wish list" for now.

In the mean time, there is the log. The log will list each recall action and the items that were recalled. You can also search the log for a specific item if you think you already recalled it.