Message |
|
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.
|
|
|
Mojave is the last macOS you can restore a bootable startup volume using QRecall. So if you follow my previous instructions (create a new APFS volume and restore your volume to that), the results should be bootable. Also... Steps for downgrading macOS:
If you're also restoring from QRecall, it's cleaner if recall your volume from QRecall before re-installing the (old) OS over it.
Download an earlier macOS installer using the (not-so-)secret App Store links.
Create a small HFS+ volume on an internal/external drive, or use a largish USB thumb drive (on computers that can boot from a USB drive).
Create a bootable installer using the createinstallmedia tool that's imbedded in the macOS installer app.
Reboot from the volume the tool just initialized and install your old OS somewhere (on a new volume, or into the volume you restored with QRecall).Note: I've noticed that using a USB thumb drive has been problematic with some recent Macs. I have a Mac Pro 2019 that I cannot boot from a Big Sur installer volume created by createinstallmedia, even though this Mac shipped with Catalina. (It starts to boot, and then just crashes.) But if I add a small volume partition to a spare internal SSD, it boots from that just fine.
|
|
|
Mike,
At that point the computer was able to boot off its system volume. But it was running Monterey. I naively expected it to be running Mojave.
Mojave is pre-Catalina, so it exists as a single volume. Catalina and on, the startup volume is a volume pair: an immutable system volume and a mutable data volume. During the Monterey install, your single volume was split into a system volume and a data volume. When you then restored your Mojave volume to it, you only ovewrote the data volume. The core operating system (Monterey) is still on the immutable system volume, so that's what'a going to boot. And yes, you've created a kind of Frankenstein OS that will probably exhibit some bizarre behavior. To jump back to Mojave, you need to completely erase the Monterey System/Data volume pair, create a new (single) APFS volume, and use QRecall to restore that. That should get you back to running Mojave, from which you can then proceed forward.
|
|
|
Mike, Sorry to hear about your trouble upgrading your OS. There are a number of paths to follow. One is the command line, but that's pretty technical. Here's my suggestions: First, start by simply trying to preform the upgrade again. This would be the simplest solution, if it works. Even if your startup drive isn't bootable, you can always reinstall the most recent macOS that your hardware supports using recovery mode. It's entirely possible that something went sideways during the upgrade (and jumping three major version in a single go is fertile ground for complications). Hard reboot your machine and start it up in recovery mode. Then just try installing Monterey again. If that works, you're done. (As much as I love it when people use QRecall to solve their problem, NOT having to perform a full-system restore is usually a simpler solution.) However, if you now believe that your startup volume has been trashed and is unrecoverable, you can restore from QRecall and reinstall macOS. The easiest way to do this is from a second bootable volume. Since you didn't create one ahead of time, create one now?and again, recovery mode and APFS are your friends:
Start up in recovery mode
Use the Disk Utilities to erase/reformat your startup drive
Create a new APFS volume on the drive named Lifeboat (or something)
While still in recovery mode, install macOS on the new Lifeboat volume (user name, passwords, settings don't matter; just keep it simple)
Now that Lifeboat is installed and booted, download QRecall and install it
Launch Disk Utility and create a second APFS volume (APFS containers can hold multiple APFS volumes that share the same space); this will be your new startup volume
Launch QRecall; open your latest archive and select the volume to restore, hold down the option key and choose Restore Volume To...
Select the volume you just created in Disk Utility and start the restore; this will take awhile
When you're done, either download the Monterey installer again from the App Store, or use recovery mode again, and install Monterey on top of the restored volume
If successful, you can use Disk Utility to delete the Lifeboat volumeNow if all of that doesn't work, then there's a serious problem installing Monterey on your startup volume. Alternative solutions would be to upgrade to an intermediate OS first (rather than trying to jump directly to Monterey). Another approach would be to install a blank version of Monterey on a new volume, then use the migration assistant to import your old startup volume, rather than trying to install the OS directly on top of an existing installation. The latter approach assumes you have enough disk space, and there are a few tricks to make that possible too, so post again if you're still stuck.
|
|
|
Johannes, We are aware of the problem of actions windows not displaying, but have yet to reproduce it here. We've tried QRecall 3.0.x on both Intel and M1 Macs, on macOS 12, 11, and 10.15, we've even tried opening the actual action documents from users having this problem and still can't replicate it. So now we're asking for beta tester help. If you're having this problem, please try the following:
Open the Console app.
Select your device (computer name)?it should be the default?on the left.
Click the Start Streaming button; you may have to enter your admin password the first time.
Enter "QRecall" into the search field, upper right.
Open QRecall.
Try to open an action window, from the actions window, or create a new action.
If the window contents are blank, continue...
Switch back to the Console app.
Click the Pause button in the toolbar.
Select everything in the window and copy it to the clipboard.
Create an email to support@qrecall.com and paste in the results.
Follow up by sending a diagnostic report in QRecall (Help > Send Report). This will help us look for anything unusual that might be getting logged by the system UI that's preventing the action windows from displaying. Thanks for reporting this, and thanks for helping make QRecall better. Beta testers are the unsung heroes of software engineering!
|
|
|
|
|