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...

Things can get a little weird when your home folder isn't on the startup volume. However, in this case I can't see any reason why your setup shouldn't have worked.

I'd suggest we start by getting a diagnostic report (in the QRecall app, choose Hello > Send Report). That will allow us to examine the actual capture and exclude paths involved. I suspect we might send you a test version of QRecall to try.

LeviTaylor wrote:Regarding the forum's transition to HTTPS, when can users expect this transition to be completed, ensuring a more secure browsing experience for all?

It's already finished.

LeviTaylor wrote:Can cycling CPU core usage help even out temperatures?

Not really. Most modern CPUs are multi-core, which means that all of the cores are on the same chip. So moving work around to different part of the same chip isn't going to change the energy expended by that chip.

It's a moot point anyway, as regular programs have absolutely no control over this whatsoever. All task and CPU switching is managed by the kernel and there are precious few influences over that.

Darryl,

Did you, by chance, "test" the stack feature by recovering the stack to a new archive? If you did, you've run the risk of reassigning the archive identifier of the original archive, so the stack now belongs to the archive you recovered, not the original.

There's a long discussion about this in the help: QRecall Help > Guide > Stacks > Recover an Archive > Archive Doppelgängers.

If you still have the recovered archive, use the steps in the "Archive Doppelgängers" sidebar to exchange the identifiers. If you don't, you can recover the stack again (just the empty archive, don't transfer any slices back), swap the identifier, and then discard the temporary archive.

But you can only do this if you haven't performed any slice transfers from the recovered archive to the stack. In other words, you didn't recover an archive from the stack, perform some captures, upload those slices, and then say "Hey, that seems to work, I'm going back to the old archive now."

If you did do the latter, or anything similar, then the safe solution is to delete your archive and recover the entire archive from the stack.

And send a diagnostic report (Help > Send Report) just so we can review your log to make sure something else isn't going on.

But this did get me thinking.

It shouldn't be too hard to put a throttle on the log output so if the process is trying to log a ridiculous amount of data, say more than 1,000,000 messages an hour, it can simply shut the log output off.

I'll put that on the wish list for 3.x

Olefin,

Olfan wrote: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.

That was clearly the right thing to do. Once the connection to the volume was broken, the helper process was useless anyway.

QRecall's pretty fanatic about logging everything it does, but even I'm having trouble thinking of anything that would generate 180GB of log data without stopping. Most logging is self-limiting: you get an error, or three, or a hundred, but ultimately the process gives up, logs one final "I've given up" message, and terminates.

The only code that will log an error and continue to plow ahead is during a repair, and that code (at least in QRecall 3.0) does limit the number of messages it logs before logging just a summary. There is also code that corrects slightly damaged data, but if the drive was dis-connected there's no way successive corrections could be successful.

So without a peak at what was getting logged, I can't offer much in the way of useful suggestions, other that what you've already done.

The server transition was a little rougher than we'd hoped, but the new site is up and running.

Let us know if you encounter any more problems.

We have a complete site redesign in the works, it just takes time. Until then, you can safely reach the site at http://www.qrecall.com/

Darryl,

www.dawntodusksoftware.com is not a scam. That's the domain for the private company that develops QRecall.

The site that's there was not supposed to be public (I forgot to exclude it from Google the last time it was uploaded). It's actually a sandbox to test the new www.qrecall.com site, which we expect it to go live about the same time that QRecall 3.0 is released.

The new site and the QRecall 3.0 release should happen fairly soon (within the next couple of months).

Steven J Gold wrote:In this case, the updated apps will be captured and the old versions of the updated apps will eventually disappear from the archive, correct? And same thing for the apps in /Applications which have been deleted (and not replaced) since the last capture of /Applications, correct?

Correct and correct!