Sorry for forgetting to enter my license key after reinstalling QRecall. I've entered the license key and updated my OS to 15.0.1, but still no luck opening my archives. Another report has been sent, and will use the email support channel from now on.

I found QRecallHelper in ~/Library/Application Support/QRecall, and added it to "full disk access" manually. Still can't get QRecall to open my archives.

Thanks for the screenshot. Mine is different. (screenshot attached below)

As said, the "com.qrecall" item got itself on the list; I only flipped the switch. Same with QRecallScheduler, which got itself on the list much later. (It wasn't there when I last posted here a day or two ago. I saw it only when I wanted to take a screenshot just now.)

How do I add QRecallHelper to the list, then?

A second screenshot is to show you QRecall's log window. Everything was installed properly as far as I can tell.

OK, that's good to know. I added QRecall to "full disk access" only after I had trouble opening any archives, as a desperate last measure.

Just to make sure, by "QRecallHelper" you mean the one shown as "com.qrecall", right?

Thanks!

OK, that's encouraging to know.

Did you install Sequoia from scratch or did you upgrade in place, may I ask? Some MacOS oddities show up only with freshly installed systems. The troubles QRecall ran into when trying to install a pair of plist files into ~/Library/LaunchAgents as I reported in my first post is a case in point. Upgraded systems would have the old permission in place and wouldn't have the problem.

Anyway, I've reinstalled QRecall and given every permission it has requested, including manually granting it full disk access. ("com.qrecall" was on the "Full Disk Access" list automatically; I only needed to flip the switch. QRecall, the app itself, had to be added manually.) Still no go.

I then removed all login items and disabled all "Allow in the Background" permissions except those requested by "James Bucanek", as shown in the attached screenshot below. Rebooted the system and still no go.

A debug report has been sent from QRecall. (I can still launch the app and get the menu at the top. I just can't open my archives.)

Hi,

Chances are you knew about this already, but since I can't find any notice on the website, I'll report it anyway.

QRecall 3.0.8 doesn't work on MacOS 15.0 Sequoia. I can't open any archive. There is no error message; nothing happens when I ask it to open an archive.

One should avoid the .0 version of a new OS, I know. I do usually wait till the .1 release. It just so happened that Sequoia came out just as I had to reinstall my system from scratch (for reasons unrelated to QRecall). I thought I could save myself another reinstall when 15.1 comes out in a couple of months.

The installation of QRecall was problematic, too, for the ~/Library/LaunchAgents folder somehow got a 644 permission setting on my freshly installed Sequoia. After it's properly set up (no more error messages in the log), I could open the Log window and Actions window, and scheduled actions (restored from my previous installation) did appear to run.

Sorry, no debug log; I wanted to test something (again, unrelated to QRecall) and had to revert my system back to an earlier APFS snapshot, so I no longer have QRecall installed.

My hardware is a Mac Studio M1 Max (2022).

Thanks for the detailed explanation. I don't have Google Drive "installed" on my system, as I use it only for backup purpose. Those cloud storage drivers are notoriously review hungry and tend to make the system less stable, and I've tried to stay away.

My current cloud backup solution is Arq, which manage cloud connections by itself, and I hope someday QRecall can do the same.

Take your time, though. No rush.

Thanks for the excellent software, as always.

James Bucanek wrote:

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.

Reading this gives me hope that maybe Google Drive or OneDrive will be supported someday? For students and people working in an educational institute, the price of Google Drive or OneDrive can't be beat--they are free, with ample space. I have terabytes backed up on Google Drive, and will never switch to iCloud or S3 for that purpose.

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?

Thanks!

Doh! How come I didn't think of making a new action. Silly me. I thought what I did in step 5 above (re-selecting the backup source and the target archive) would be the same. Apparently it isn't. After removing the old action and made a new one, RB3 does capture following file changes. Thank you!

I might have run into another bug, though, while making the new action: the details of the schedule--specifically the length of the delay and the length RB should ignore new events after a capture run--don't always stick.

E.g., the last thing I did before sending in the diagnostic report was to change the delay from 3 min. to 5 min. and to ask RB to ignore new events for 20 min. The second change was kept while the first one was ignored. The delay remains 3 min.

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.

Thanks

Hi,

I decided to start test driving QRecall 3.0 beta yesterday. All seemed to be fine until I realized just now that one of my archives using event-based capturing schedule--to run when "capture items change" with a 3 min. delay to be exact--had not run since QR 3 beta was installed.

What I have tried so far:

1. A manual run from the action window that went smoothly--no difference.

2. Reboot my system--no difference.

3. Tweaked the scheduling details a little bit (from 3 min. delay to 5 min. delay) -- still no go.

4. Tweaked the scheduling details some more, this time removing the "ignore new events for 20 min." restriction -- still no difference.

5. Tweaked the scheduling details again by re-selecting the target archive and the "item to capture" and changing the delay back to 3min -- still no difference.

After each step above, some files on the backup source (the drive selected as the "item to capture") were changed to make sure new file change events were triggered. One of my cloud sync tools (Syncovery) also works on file-change events-based scheduling, and it sync'ed all the changes dutifully.

More details about my system:

I'm running QR 3.0 beta v.74 on a hackingtosh desktop on freshly installed (not upgraded) Mac OS 12.1. QR version 2.2 was installed first before upgrading to 3.0 B74. QR2 has been working on the system for years. With QR2 and now QR3 beta I have two active archives. The other one is on time-based capturing schedule (every 6 hours) and is working uneventfully.

Thanks for listening.

10 hours have passed since the drive hosting those archives have been reformatted into HFS+, and there is no sign of either archive taking up any ghost space (checked in Finder and with df & du, as usual). It's now pretty clear it's APFS-related (& most likely an APFS bug). Thanks to Adrian for bringing the possibility to my attention, though I have no clue if/how it's related to the issues mentioned in the discussion thread you provided.

I had decided to leave the volume as is, but an itch made me give APFS one final chance. This time, I erased the whole drive (yesterday I merely reformatted the APFS volume without touching the container/partition). I'll report back if I find something interesting.

James Bucanek wrote:So if this is the discrepancy, it might be something you can just ignore.

It's not. I thought I have made that clear. I was only arguing that it's not useless to take snapshots of a volume dedicated to hosting QRecall archives.

I'm going out in a min., will report my findings after I'm back.

James Bucanek wrote:Because of the issues I've encountered with APFS volumes getting corrupted, and since you mentioned that you have the space available to move the archives to a different volume, I'd suggest copying the archive to another volume, repartition and reformat the APFS volume, then move the archives back.

It's what I did earlier this evening, and it didn't help as said in the previous post (before I saw your latest post).

James Bucanek wrote:Also, you mentioned that "I take a system snapshot of the boot volume", but we're talking about the volume the archives are on, right? There shouldn't be any snapshots of 'zoo'. (It doesn't make any sense to make a snapshot of an archive volume, since archives are literally a collection of snapshots/layers.) If there are, that could be the problem?at least the root of the free space problem.

Yes, I meant only to take a snapshot of the boot volume (with "sudo tmutil snapshot /"). I didn't know tmutil actually took a snapshot for each active volume. (Well, I didn't check them all, but I did check a couple and they all had a snapshot of the same timestamp.)

That being said, I don't think it's useless to take snapshot of a volume dedicated for backups, as system snapshot and cloud backup are the only two means I know that can withstand a ransomware attack.

OK, what I did a few hours earlier doesn't seem to help as docm.quanta is still putting up weight. (I changed uial.quanta's schedule back to one capture per day, so it's fine.)

Given your conversation above, I'll try something new tonight. I moved the two archives away, again, reformatted the drive into HFS+, and moved the archives back. We should find out if APFS is the culprit tomorrow morning. (It's 1am local time, and I'm going to bed.)

Less than 5 hours into my experiment, both archives have put up substantial weight:

44G	./uail.quanta

  0B	./.Trashes

320K	./.fseventsd

143G	./docm.quanta

  0B	./.TemporaryItems

187G	.

Apparently the issue is not archive specific.

Other than compacting both archives, I decided to try something different this time. I moved both of them to another drive (drive B), reformatted the original drive (drive A), and then move them back.

As soon as the first "move" action completed, drive A got all its missing space back according to Finder, concurred by df, and du. On drive B, "du" reported normal size for both:

15G	./uail.quanta

 19G	./docm.quanta

 34G	.

As expected, they are still normal after being moved back to drive A.

Another report has been sent.