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