QRecall

Quick update on the stacks issue:

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.
I did manage to remove the stack's association to the archive by moving it into a hidden directory and chmod'ing that directory to 000, though, and then trying to delete it. The archive lost its connection to the stack but couldn't actually destroy it.
Reconnecting the stack after putting it back into place worked fine. Checking the cascade scheduled action seemed okay, running it wouldn't work, though.
I then edited the Cascade action to no stack, saved, then edited it again to the stack I wanted, saved, ran, no luck.
Still, the stack can be updated from within the archive through the »Layers«->»Stack slices« menu and audited via the sidebar.

Looking at the action plist using plutil -p does point to the correct stack guid, it is the same guid as found in both the ~Libraries/Preferences/QRecall/Stacks/ folder and the archive folder as <guid>.qrstackconfig.
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.
Some experimentation changing the case of the guid (which is mostly uppercase in the plists and lowercase in the filesystem) didn't show any success. My APFS volumes are case-insensitive anyway so I didn't expect anything there, but changes to the plists didn't have an effect either. Can't see why it gets a nil instead of the guid that's there.

Hi James,
I hope you're keeping well. Since moving to MacOS Sonoma (new Mac came with it) and QRecall 3.0.5.1 I've noticed two phenomena I can't quite explain and would like to ask your council.

0) background
My QRecall archives and stacks live on APFS volumes connected via iSCSI, physically being hosted on a NAS box in my office and another in my home (stacks are VPNed in). This seems rock solid, I have my Photos library, Music library and client projects on such volumes and especially the latter are doing some crazy i/o at times but never fail. MacOS knows they're not truly local volumes but treats them as such for all practical purposes.

Before moving Macs, OS versions and QRecall versions (I'm so sorry about that, I know that's nigh impossible to debug and I should have tried to move one change at a time) all QRecall actions ran like clockwork.

1) "permissions" issue
Every now an 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.

The files and directories are mine (user 501), they have all the permissions they need and I'd never wittingly change them. Currently they co-belong to the group "staff", I'm open to changing that to "wheel" or "admin" or anything if it can help. But why does this issue crop up in the first place? The repair action doesn't make any changes to permissions that I can detect.

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.

But: opening an archive I can see the stack(s) in the sidebar, and I can manually cascade to a stack or audit it just fine.

Is there anything I can try to fix this on my end?

Best of regards,
Olfan

Just a quick update:
this was a one-time event, it didn't repeat and I can't seem to trigger it at all (which is great).
I've moved Macs in the meantime, taking the opportunity to move to QRecall 3.0 as well.
Should I ever observe a similar event, I'll (hopefully) remember this thread and dig it up again.

A weird anecdote:

Yesterday, one of my storage devices decided to activate a patch on its own schedule - an action I had expressly forbidden. It took down an iSCSI target that my Mac was currently using to run a capture action to. When the service came back seconds later, the volume was re-mounted, and QRecall proceeded to touch the .lock file inside the archive but wouldn't write anything to the archive files themselves anymore/again. As I noticed a few minutes later from the alarms going off, it did write several hundred MiB/s of text into QRecall.log, though. By the time I took notice the log file was some 180GiB in size. I panicked, killall'ed QRecallHelper and deleted the QRecall.log so it wouldn't choke my Mac with clogged local storage.

When I came to, I realized I should have taken a sample of that log, maybe just a »tail -1000« of it, so it could be analyzed. I am sorry about that, but there's nothing I can (am willing to) do now.

I'm relatively certain that the log grew so big so fast because the same message was written to it over and over. The volume will have appeared to QRecall as local APFS drive, maybe it has code to deal with breaking network shares but can't cope with local disks vanishing? Maybe QRecall wants to consider skipping such messages if they occur more than a number of times per duration, or cease logging if there's been more than a certain amount of log per duration?

I'm not claiming there to be any malfunction, just sharing this so it might get attention if it needs it. It's QRecall 2.2.14.1 on macOS Ventura 13.4 on a 2020 M1 Mac mini. As always, I'm absolutely willing to help debug whatever I can if prompted to.