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.

Sorry to hear you're having so many problems, but I suspect the manual un-install fixed whatever problem was preventing your privileged helper service from installing.

Mats Jacobson wrote:I attempted a detailed uninstallation followed by a new fresh installation after a restart and while I now get QRecall 2.1.8 properly opened I lost my schedule Actions for the main archive. Are these possible to recreate? I still have most files I think.

Each QRecall action is stored as an action file (.qraction) in the ~/Library/Preferences/QRecall/Actions folder inside your home folder. Each file is automatically named (e.g. important stuff-compact_0.qraction) in a way that should make it easy to identify what that action is.

If you have copies of your action files (say, in the archive that captures your home folder or still in your Trash), simply move/copy/restore them back to that folder and restart your system.

If you're a little bit geeky, you don't have to restart your whole system. The QRecall app and the background scheduler look at the Actions folder when they start up and after you make any changes to your actions. But if you manually alter the files in the Actions folder, you'll need to nudge QRecall into loading the Actions folder again. The quickest way to do that is to re-launch the QRecall app and the QRScheduler process. The later can be restarted using the Activity Monitor app; use the search field to find the QRScheduler process and tell it a "Quit" (a TERM signal, if you want to do this from the command line). It will immediately restart and reload the actions in the Actions folder.

Mats,

It seems you have a weird, partial, installation. You definitely have a scheduler installed and running, but it's the 2.1.4 version (which is why QRecall refuses to recognize it).

But the real problem is that you have privileged services installed, but your system isn't preauthorized for administrative privileges.

My guess is that at some point QRecall prompted to upgrade its privileged helper service and something went wrong, so the pre-authorization went away leaving some services installed/updated and others not.

I suspect you can solve this simply by launching QRecall and going to QRecall > Preferences. Choose the Authorization tab and check the "Capture and recall items with administrative privileges" option.

QRecall should then prompt for your administrator's account and password. If successful, it should install the privileged helper service.

Count to three, quit QRecall, and launch it again. If I'm right, everything should get reinstalled and start working again.

If I'm wrong, you know how to send another diagnostic report...

Nico,

QRecall logs almost every reason it does or does not do something, but sometimes it's considered "minutia" so you might need to slide the Details level in the log window further to the right.

If you don't thing somethings working, start by sending a diagnostic report. Open QRecall and choose Help > Send Report from the menu.

That will collect your recent log activity (a lot of which you don't normally see), crash reports, and configuration information that will hep us figure out what's going on.

Mats,

Let's start by getting a diagnostic report. Open QRecall and choose Help > Send Report from the menu.

That will collect your recent log activity (a lot of which you don't normally see), crash reports, and configuration information that will hep us figure out what's going on.

Nico,

QRecall can certainly help you. Although, if I'm being completely honest, you don't need QRecall to accomplish this.

Here's how I'd do it using QRecall:

(1) Format and install Sierra on an external drive.
(2) Download and install QRecall
(3) Using the capture assistant to create an archive on the external drive and capture your entire startup volume. (Have a snack while QRecall does its thing.)
(4) Boot from the external drive
(5) Use Disk Utility or whatever you need to replace/erase/reformat your internal drive.
(6) Download and use the High Sierra installer to install a fresh OS your empty internal drive.
(7) Download and install QRecall again (or just drag the copy of QRecall from the external drive on to the internal one).
(8) Open QRecall and open the archive on your external drive.
(9) Selectively recall the items you want. You can do this simply by dragging an item from the archive into Finder to re-install or replace the items on your new system, exactly as you would using the Finder.
(10) Enjoy

Notes:

- In step 9, QRecall's "Restore" command won't work because your internal volume is brand new and is no longer the source of the items in the archive.

- Make sure that the "short" (UNIX) name of your new account(s) matches your current account(s). If you do that, Qrecall will automatically fix up any ownership issues when you recall the items so they continue to belong to the same users (something a clone or straight copy utility won't do).

If you want to continue using QRecall, you're already done 90% of the work of setting up an bootable external volume for performing catastrophic recoveries. All you'd need to do now is use the capture assistant to set up regular capture strategy of your new startup volume to the existing archive on the external drive (and with QRecall's data de-duplicating, it won't even get any bigger). And then you'll probably want to upgrade the external drive so it's running High Sierra too.

Let us know if you have additional questions or run in to any problems.

Here?s one solution, that assumes you?re using Apple Mail.

First, update to QRecall 2.1.7. There?s a bug in 2.1.6 that doesn?t reliably run the epilog script after an error.

Launch the Script Editor (built-in app the comes with macOS).

Create a new document and paste in this code:

set commandSuccess to (system attribute "QR_COMMAND_SUCCESS")

if commandSuccess is "0" then

	-- the command's success is "0" (in other words, the action was NOT successful)

	-- note: if the action was canceled, QR_COMMAND_SUCCESS will be "1" and QR_COMMAND_CANCELED will be <who>,

	--	so if you want to be notified of canceled actions you'll need to add a check for that.

	-- note: that if run as a prolog, there is no QR_COMMAND_SUCCESS value, so this will never execute

	

	-- compose a message with a summary of the problem

	set recipientName to "QRecall Administrator"

	set recipientAddress to "your@email.com"

	set theSubject to "QRecall action failed"

	set theContent to "The QRecall action '" & (system attribute "QR_COMMAND_TITLE") & "' failed." & return & return ¬

		& "Reason: " & (system attribute "QR_COMMAND_EXCEPTION") & return & return ¬

		& "Archive: " & (system attribute "QR_ARCHIVE_NAME_DISPLAY")

	

	tell application "Mail"

		-- create the message

		set theMessage to make new outgoing message with properties {subject:theSubject, content:theContent, visible:true}

		-- set a recipient

		tell theMessage

			make new to recipient with properties {name:recipientName, address:recipientAddress}

			-- and send the message

			send

		end tell

	end tell

end if

Edit the value of the recipientAddress at a minimum, but feel free to customize the name, subject, and content values to suit your needs.

Save the file as a compiled AppleScript (.scpt) file.

In QRecall, open the actions you want to be notified, by email, when they fail. Click the ?Select? button in the Epilog script and select the AppleScript file you just saved. The ?Needs UI? option should automatically get checked, but just make sure it is. Save the action.

That?s it.

After each edited action runs, it will execute this AppleScript which will see if the action finished successfully, or at least non-fatally. If it was successful, it does nothing. If there was a failure, it opens the Mail app, composes, and sends a message to the address in recipientAddress.