I was just about to post on how to manually add the QRecallHelper app to the full disk access list, but you figured it out already.

If you haven't sent a diagnostic report, do so now (in the QRecall app, choose Help > Send Report).

I received a diagnostic report that I believe is yours, but the report is anonymous. If it is yours, that means you have not installed your identity key and you didn't provide a contact email address in the report. Also, the log records in that report show no attempt to open an archive or run any actions. So I'll need some clarification on what you mean by "can't open an archive" because there are no archive access failures logged.

If you have more details, sending those to QRecall Support will likely be faster than using the forum.

Finally, opening an archive for browsing in the QRecall app shouldn't require any exemplary permissions. QRecall archives are regular documents which should be accessible to the user account that has QRecall installed, like any other spreadsheet or music file.

The QRecallHelper process, however, performs the actually capture and recall of items and often needs elevated user privileges to accomplish its work. That's why QRecallHelper is the one (and only) component that's a candidate for Full Disk Access.

Ming-Li Wang wrote:Just to make sure, by "QRecallHelper" you mean the one shown as "com.qrecall", right?

It should appear as "QRecallHelper":



The "com.qrecall" is likely the identifier of the privileged elevation service, which does not need Full Disk Access.

Ming-Li Wang wrote:Anyway, I've reinstalled QRecall and given every permission it has requested, including manually granting it full disk access

For the record, the only QRecall component it makes sense to grant "Full Access" is the QRecallHelper component. This is the executable that does all of the real work in QRecall, including capturing and recalling items.

Most of the other QRecall applications and component don't access anything beyond the archives and your preferences. Although granting "Full Access" to everything won't (likely) harm anything, the best security practice is to limit the access of applications to just what they need and nothing else.

Sorry to hear you're having difficulties.

QRecall is definitely compatible with macOS 15.0 (Sequoia). I'm running it here, and I've heard from dozens of other users who are too.

With any major upgrade, macOS can be persnickety about software that's installed at the OS level and given elevated privileges. The usually solution is to just uninstall the software and resinstall it.

Given the problems you're describing, it's likely that macOS is blocking the low-level components from executing. The side effect is that the QRecall application can't uninstall itself (since it needs those components to accomplish that—catch 22).

So you'll want to run the uninstall utility script buried inside the QRecall application bundle, like this:

Quit all of your other applications (the uninstall will perform a system restart, so you want to make sure you've saved your work).

Open the Terminal app

In the terminal, execute this command:

/Applications/QRecall.app/Contents/Resources/uninstall.sh

The command will prompt you for your administrator password, uninstall all active QRecall components, and then restart your system.
(Note: this assumes QRecall is located in your /Applications folder; if it isn't, adjust the path accordingly.)

Following the restart, launch the QRecall application and let it reinstall itself.

macOS may than ask you to authorize various QRecall components to have access to external volumes, etc., to which you should agree.

That should resolve your problems. Let us know if it doesn't.

Hello Steven,

For all kinds of reasons, QRecall components can be mis-installed, or get mis-updated, or just don't run.

The simplest solution to these kinds of problems is to completely un-install QRecall and then reinstall it from scratch.

In QRecall 3, this is most thoroughly accomplished using the "uninstall" script included in the QRecall application bundle. To do this, follow these steps:

Quit all of your other applications (the uninstall will perform a system restart, so you want to make sure you've saved your work).

Open the Terminal app

In the terminal, execute this command:

    /Applications/QRecall.app/Contents/Resources/uninstall.sh

The command will prompt you for your administrator password, uninstall all active QRecall components, and then restart your system.
(Note: this assumes QRecall is located in your /Applications folder; if it isn't, adjust the path accordingly.)

Following the restart, launch the QRecall application and let it reinstall itself.

That should resolve your problems. Let us know if it doesn't.

JoeMFox wrote:Thanks a lot, I am really impressed by the service you are providing!

Yes, the restart solved it, so it is working as expected.

That's a relief to hear!

in the older version, when creating a new archive, the "Data redundancy" by default is set to "1:8" (which I think is a good choice); but the current version, by default, redundancy is switched off.

I was encountering too many customers who had redundancy turned on for archives stored on RAID or cloud drives, which themselves provide their own error correction, which is—dare I say it?—redundant. So I made this particular feature "opt-in".

BTW: when I find some time I might test the redundancy (by "destroying" some data using a hex-editor)

Have fun! That's the way we test it here. (I even wrote a custom tool that scrambles random bits of a file so I could automate the tests.)

JoeMFox wrote:the advanced setting "QRExcludeCasheExcludesMail" (as you described) does not exist; instead there is a setting "Excluding Cache or TM excludes Mail"; I guess, this is the correct setting.

The defaults setting key is QRExcludeCasheExcludesMail—that's the value that gets set in ~/Library/Preferences/com.qrecall.helper. The "Excluding Cache or TM excludes Mail" is its human friendly description in the advanced settings panel. When you open the value for editing it will show you the equivalent defaults command.

There is, however, a long standing bug in macOS wherein a defaults setting set by one app for a different app isn't immediately visible to the second app. The easiest way to correct this is to restart the system and check the setting again. If it's still set, try the capture again.

I have done several tries:
- I also have tried "Items exclued by TimeMachine" (in this case caches are grayed out)

Time Machine exclude cashes, so one implies the other.

The easiest way to test if the setting is working is to use the command line:

qrecall capture /Path/To/Archive --deep ~/Library/Mail

I tested it here and it's working, so my suggestion is to just restart and try again.

JoeMFox wrote:why not just add another checkbox liek "ignore emails (use only for IMAP mails)" ?

I have a lot of boring reasons why I don't want to do that (just yet).

And: as you mentioned, it would be good to know, what the "Cache" checbox is doing (so any user should be able to recreate the behavior by own setting).
In general, for every checkbox which affects more than just a simple file or folder, every user should be able to fully understand what this checkbox is doing.

This answer used to be simple, but as macOS has matured it's become progressively more complicated. Right now, the short answer is there are a set of items excluded when you turn on the "Exclude caches" option:

/private/var/folders
/System/Library/Caches
/Library/Caches
~/Library/Caches
~/Library/Containers/*/Data/tmp/*
~/Library/Containers/*/Data/Library/Caches/*
~/Library/Mail/V*/*
Where ~ is every user's home folder defined in the system.

So for now, I've implemented a new advanced setting (QRExcludeCasheExcludesMail) that turns that last filter rule (Mail/V*) on or off. You can download this pre-release version of QRecall to try it out.

To capture the Mail folder with "Exclude Caches" or "Exclude Items Excluded by Time Machine" turned on, do this:

1) Go to the QRecall > Settings > Advanced
2) Edit the "Excluding Cache or Time Machine excludes Mail" setting. Click the setting until it is un-checked.
3) Save the new setting.

The next capture that captures that folder should recapture everything. But there is some weirdness when changing the ad-hoc filters between capturers because QRecall relies on the filesystem change history to determine which folders needs to be examined, and the change history doesn't reflect that fact the the filters changed. So to be absolutely sure, do this:

4) Open the capture action that captures your home folder
5) Set the "Deep Scan" option
6) Save the action (File > Save)
7) Run the action

Once the action is running, you can turn the "Deep Scan" option off and save the action again. The "deep scan" run will cause the capture to ignore the filesystem change history and iterate through every folder in the captured item.

JoeMFox wrote:I think it is a very bad idea to "hide" emails under the "cache" entry, because it is not obvious that emails belong to "Cache"!

In general, I agree with you on all points. The current mail exclusion filter is basically a hack because I couldn't really come up with a "real" solution.

As I mentioned, you could simply create a second archive for just your mail.

I could also easily add an advance settings that would disable the new ad-hoc Mail filter, restoring QRecall 3 to the behavior of QRecall 2. If that would be of interest to you, let me know here or write to support.

What I'd really like to find is a straighforward way to mark all of the data storage for IMAP mailboxes as cache and capture everything else. Maybe a shell script? Just thinking out loud.

After first (new) backup (of my user-folder) I tested restoring some files.
And I found: my emails are missing in the backup.

That is correct.

In QRecall 3.0.7 and later, if you check either the "Exclude: Cache" or the "Exclude: Items Excluded by Time Machine" option, the contents of any ~/Library/Mail/V* folder will be excluded.

This is because most of the world has migrated to IMAP, and in IMAP the contents of your mail folder are simply cached copies of what's on the server(s). Additionally, recent changes to the Mail program have made these folders immensely complicated and time consuming to capture.

If you have POP or local mailboxes that must be captured, and you do not want to turn off both of the exclude options above (which I would not recommend), then the most straightforward solution is to create a second archive just for mail. Set it up so that it does not exclude "Caches" or "Time Machine" items, and then schedule a capture to capture just the specific POP or local mailboxes you need to preserve. (Again, avoiding any IMAP accounts/mailboxes because capturing these is largely a waste of time.)

Jeffrey wrote:Looks like it is simply recapturing the next time a backup is performed. The drive is listed in the Archive Preferences Specific Items dialog box as simply

/UserName/ExcludeMeDir

This might be because your home folder is mounted on an another (not the startup) volume? This creates confusion for the bookmarks.

I deleted this so there are no entries in the Specific Items section and I'll trying entering it as a reg exp pattern now:

path
//Volumes/OtherHD/Users/UserName/ExcludeMeDir

pattern:
*

infinity: checked

Close

Absolute patterns are anchored to the root directory of each volume.

You'd actually want something like this:

/Users/UserName // ExcludeMeDir [ ] glob

To exclude the entire folder, or to be more subtle:

/Users/UserName/ExcludeMeDir // * [ ] glob

to exclude just the contents of that folder.

If you're still having problems, there are even more esoteric things to try.

Jeffrey wrote:Is there a way to delete a directory and it's contents from an archive that's already created ... ?

Absolutely.

Open the archive and navigate to the item(s). Select it (them) and choose Archive > Delete Items.... (See Help > QRecall Help > Guide > Advanced > Delete Items)

This will "uncapture" that item in all layers of the archive, as if it had never existed during the previous captures.

If the item still exists on your hard drive, you will want to make sure it is excluded from future capture, otherwise it will just get captured again next time. (See Help > QRecall Help > Guide > Preferences > Archive Settings and read the sections starting with "Excluded Items").

Apologies for this problem. A recent "fix" for display problems in Sonoma inadvertently broke the capture assistant.

This pre-release version of QRecall 3.0.6 should solve this problem. Download it and send a problem report if it doesn't resolve this issue.

Olfan wrote:I could not make a "Disconnect" option appear. Holding the Option key changes the "Delete" to "Reconnect", also holding down Cmd and/or Shift doesn't do anything further.

Not Command, Control. Option+Control changes to "Delete" to "Disconnect...", ... but you figured it out

Checking the cascade scheduled action seemed okay, running it wouldn't work, though.

This also isn't making any sense, since both the action and the interactive command end up doing the same thing: launching a background instance of QRecallHelper to preform the action.

I'm also seeing really anomalous messages in your log, like this one:

unreadable sequence file; using legacy sequence

Which makes no sense because this file gets recreated during the repair and is readable by the user.

So I have to suspect that there's some strangeness(™) going on with the storage device and/or the security framework.

I have two suggestions.

First, make sure there are no restrictions on QRecall by going to the System Settings > Privacy & Security > Files and Folders. Find the various QRecall component (particularly QRecallHelper) and make sure everything is enabled. (Alternatively, add QRecallHelper to the Full Disk Access category.)

Second suggestion is, if the QRecall02 volume is only used for QRecall archives, select the volume in the Finder, choose Get Info, and at the bottom check "Ignore ownership on this volume".

I did notice that the qrstackconfigs in the archive and in the Stacks prefs folder differ in many places but couldn't see what the differences mean.

UUIDs are case insensitive, pretty much everywhere in QRecall.

Can't see why it gets a nil instead of the guid that's there.

It would appear that it can't read the file, just like the regular actions can't read the sequence.index, neither of which makes any sense.

And if you try any of these suggestions, please follow up with another diagnostic report. Thanks!

Olfan wrote:1) "permissions" issue
Every now a then an action will fail saying "archive package does not have modify access" (/Volumes/QRecall02/something.quanta for example). Once this happens, no scheduled action will work on that archive until I run a quick

qrecall repair something.quanta/ --monitor --options noautorepair,correct

which fill fix the issue, but sometimes only for one or a few actions before the problem comes up again.

That is an odd one. One of the things that might help is, as soon as it happens again, send a diagnostic report. (Help > Send Report in the QRecall application.) This will upload recent log activity as well as the state of your archives, which might provide some clues.

Spoiler alert: anytime something goes wrong, I'm going to suggest you send a report.

2) all Stacks are "undead" now
All scheduled actions that try to cascade to or audit a stack don't work anymore. They all say: "stack is not defined" "id: (nil) Expected: <some uuid>". This is true even when I create a completely new audit action and choose the archive by hand (not recent list) and pick a stack from the dropdown list the action editor filled for me with the stacks it knows actually exist. Running that action via schedule or via "run immediately" will consistently not work.

Also very strange, but here's what you can try:

First, disconnect the stack from the archive:

Open the archive in QRecall

Show the stacks sidebar

Hold down the Shift + Control + Option keys while clicking on the action menu to the right of the stack. Choose "Disconnect..."

This erases the stack configuration in the archive without destroying the stack container.

Now, reconnect the stack to the archive:

Open the archive in QRecall

Hold down the Option key while choosing New > Reconnect Stack... in the main menu.

Now enter, setup, or choose the same stack container you had before.

If all goes correctly, the archive and stack will be reconnected.

Now open each stack action and make sure the correct stack is selected.

Let me know if that helps. And if if doesn't, send another diagnostic report...