https://forums.qrecall.com/forums/show/5.page JForum - http://www.jforum.net
[b][tt]QR_COMMAND_SUCCESS[/tt][/b]: This is '1' if the command finished normally. Note that this does not mean "complete". It means there was not a failure. Cancelling an action is not considered to be a "failure."

[b][tt]QR_COMMAND_CANCELED[/tt][/b]: This variable is only present if the command was canceled. So if you want to do something when an action is canceled, you need to look for the presence of this value. The value is a number that indicates the source of the cancel message. For example, the value '4' means that a [tt]TERM[/tt] (i.e. "Quit") signal was sent by another process. It is not a user or process ID. See the [url=https://www.qrecall.com/sc/qr/help/3_0/English.lproj/guide/auto/action_scripts.html]documentation[/url] for a complete list of possible values and their meaning.

[b][tt]QR_COMMAND_EXCEPTION[/tt][/b]: The documentation isn't actually correct on this value. It will certainly be present if [tt]QR_COMMAND_SUCCESS[/tt] is '0', but it can also be present if something (like a user cancel) interrupted the normal progress of the action. This is, I believe, what you're seeing in your example.

I hope that helps a little, and if you follow up with a description of what you'd like your script to do I'm confident that something can be crafted that will accomplish that.]]> https://forums.qrecall.com/posts/preList/749/12357.page https://forums.qrecall.com/posts/preList/749/12357.page GMT
/UserName/ExcludeMeDir[/quote]
This might be because your home folder is mounted on an another (not the startup) volume? This creates confusion for the bookmarks.


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

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

pattern:
*

infinity: checked[/quote]
Close ;)

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

You'd actually want something like this:
[code]/Users/UserName // ExcludeMeDir [ ] glob[/code]
To exclude the entire folder, or to be more subtle:
[code]/Users/UserName/ExcludeMeDir // * [ ] glob[/code]
to exclude just the contents of that folder.

If you're still having problems, there are even more esoteric things to try.]]> https://forums.qrecall.com/posts/preList/4887/12062.page https://forums.qrecall.com/posts/preList/4887/12062.page GMT Your choice!

As you observed, QRecall's data de-duplication means that capturing the new volume to your existing archive won't make it much bigger because most of the new volume is a copy of what's already been captured.

The question is really, do you want to keep the history of changes from your old system? If so, then keep the archive. You'll end up with an archive that has two volumes, which you can then use the Combine Items command to stitch into a single volume so you keep an unbroken history of your files.

If you really don't need that history, proceeding with a new archive makes for a clean start.

Enjoy!]]> https://forums.qrecall.com/posts/preList/637/6624.page https://forums.qrecall.com/posts/preList/637/6624.page GMT [quote]That doesn't make much sense (to me). Actions are stored locally in your QRecall preferences[/quote] I didn't make sense to me either. And I can't recreate it now. I think that maybe it was just combination of weirdness from renaming plus the fact that I had been away so all of my actions had been paused for a month. I don't know. But all is well now, so onward! :-)

[quote]I suggest leaving Show in dock on.[/quote]
Ok. I did that. It doesn't need to be completely stealthy. I actually decided to turn back on Show when actions start, too. I want her to know what's going on with her computer. So I think that's a good balance.

[quote]you might simply open the archive from time-to time and see if new layers have been added for the other owner. [/quote] Ok, I'll do that.

Thanks for everything!]]> https://forums.qrecall.com/posts/preList/2674/6536.page https://forums.qrecall.com/posts/preList/2674/6536.page GMT
In general, you've got it in the right order: capture, merge, compact, verify.

Merge has nothing to do until something is captured and time has passed.
Compact has nothing to do until something is merged (or manually deleted).
Verify always verifies everything, but will be [I]slightly[/I] faster after a merge and compact because there's less data to verify.

Now, if your goal is for your computer to spend less time maintaining the archive, there are some techniques for running the big actions less often.

[u]Using less aggressive actions[/u]

Compact is optimized so that if there's nothing to remove (post merge), then the command will finish immediately. Similarly, if the compact determines that only a small amount of space would be recovered, it also stop immediately and reevaluates again the next time it's run.

So the capture and compact command can be scheduled to run every time the volume connects, and they won't waste hardly any time.

Merge, like compact, will first determine if there's anything to do and, if not, will stop almost as soon as it was started. So you can schedule the merge to run repeatedly, but if you configure it so the first tier to merge is broad (say with week tiers), then there will only be layers to merge once a week. If the first tier to merge is month tiers, then it will kick in once a month. And, subsequently, the compact won't have anything to do until something is merged.

[u]Using schedule conditions[/u]

Finally, you probably don't need your verify to run daily (unless you're paranoid). Once or twice a month should be sufficient. To accomplish that, you'll need to do a little schedule hacking.

Change your the verify action's schedule to something less often (say the 2nd and 4th Friday of the month). Now the verify will start at a specific time. But what if your archive isn't connected? If not, the action will simply fail with an "archive not found" error.

The trick is to add a "hold if no archive" condition to the action's schedule. This tells the action to start, but if the archive isn't online it will simply pause until it is. In your activity monitor you'll see "Verify My Archive ... waiting for archive". When you do finally connect it, the waiting action will immediately resume, perform its action, and go away until the next interval.

You can also use this technique on the other actions too, as an alternative.

Bonus tip: if the entire drive is dedicated to QRecall archives, you might consider adding a "cancel if free space ..." condition to your compact action's schedule, which will prevent the compact from running at all until the free space of your drive drops below a particular threshold. This usually prevents the capture action from doing anything for months, and then?[b]boom![/b]?it performs one massive (highly efficient) compact, and it's done for another season.

Let use all know if that helps.

]]> https://forums.qrecall.com/posts/preList/2565/6337.page https://forums.qrecall.com/posts/preList/2565/6337.page GMT
The exclusion pattern approach would also work. And, in fact, I can think of another good use for it. So thank you so much because I had never set up an exclusion pattern but now that I see how it's done it makes perfect sense. Really appreciate it.]]> https://forums.qrecall.com/posts/preList/2500/6201.page https://forums.qrecall.com/posts/preList/2500/6201.page GMT https://forums.qrecall.com/posts/preList/2393/6032.page https://forums.qrecall.com/posts/preList/2393/6032.page GMT Thanks a lot James

]]> https://forums.qrecall.com/posts/preList/2333/5903.page https://forums.qrecall.com/posts/preList/2333/5903.page GMT That will require only one change monitor. It doesn't matter how many subfolders, or how deep, that folder hierarchy is. It could contain thousands of subfolders, macOS doesn't care.]]> https://forums.qrecall.com/posts/preList/1904/5172.page https://forums.qrecall.com/posts/preList/1904/5172.page GMT
A rolling merge is a merge action that groups older layers into time periods (days, weeks, months, years) and, as the layers age, automatically merges those groups into single layers.

In your example, a rolling merge something like
[code] Keep most recent: 9 months
Followed by:
0 day layers
0 week layers
0 fortnight layers
12 month layers
1 year layer[/code]
would do approximately what you're asking. When you run this rolling merge action, any layers within the past 9 months would be preserved. Layers in groups of months, going back 12 more months, would be merged into single layers (one layer per month). Any layers in the pervious whole year would be merged into a single layer, and then anything before that would be merged into its own layer.

So if you ran this today (January 2020), the merge would:

Leave whatever layers you'd captured since April 1, 2019 untouched (that's the "keep" part)

Merge all layers in March, 2019 into a single layer
Merge all layers in February 2019 into a single layer
Merge all layers in January 2019 into a single layer
....
Merge all layers in June 2018 into a single layer
Merge all layers in April 2018 into a single layer

Merge all layers between April 2017 and March 2018 into a single layer

Merge all layers before April 2017 into a single layer

The beauty of the rolling merge is that it "rolls." You can run this action twice a day if you want, but it would only do something if there were multiple layers within a group. For this action, it wouldn't do anything more until you ran it again in February.

When this action runs again in February 2020, now there are a group of layers in April 2019 that get merged into a single layer. And when it's run in October of 2020, all of the single-month layers between January 2018 and December 2018 now fall in the year tear and get merged together.

The new rolling merge action editor has a really cool (if I don't say so myself) animation that will let you preview the effect of the rolling merge as you edit it.

And there's always QRecall Help > Guide > Actions > Layers > Rolling Merge.

Post again if you have any more questions.]]> https://forums.qrecall.com/posts/preList/1747/4889.page https://forums.qrecall.com/posts/preList/1747/4889.page GMT
None of the QRecall background components should be keeping any open files on external volumes, except the binary executable files themselves ... and those shouldn't be on volumes that would ever be unmounted while the system was running. The scheduler and monitor will [i]occasionally[/i] check the reachability and status of archives and it may watch for changes in certain directories, but neither of these should prevent a volume from unmounting.

I also noted that the path [b]/Volumes/xxxx/Users/yyyyy/Library/LaunchAgents/com.qrecall.scheduler.plist[/b] might indicate that your home folder is not on the startup volume, which could complicate your installation.

Finally, [b]launchctl unload[/b] is a legacy command that's no longer supported; I'm not even sure it would work. Even if it does your command is targeting the wrong session type.]]> https://forums.qrecall.com/posts/preList/1537/4611.page https://forums.qrecall.com/posts/preList/1537/4611.page GMT https://forums.qrecall.com/posts/preList/1015/3824.page https://forums.qrecall.com/posts/preList/1015/3824.page GMT
QRecall will certainly reduce the data to its minimum amount. And don't forget to turn on compression too!

Creating a disk image of the archive won't provide many benefits and will actually make the archive a little larger.

---If, on the other hand, you want to create the absolute smallest possible file to upload consider creating your archive with compression off and then create a compressed disk image (disk image compression is more aggressive than QRecall's) Warning: that is going to take a long time and need double the space of the archive.---

The biggest problem I see is reliably uploading a single, gigantic, file to the server in one shot. 2TB of data, even if you have a 100Mb/sec internet link, it going to take a couple of days to upload. If Google Drive's software will handle partial transfers, failures, and restarts, etc., then use that. Otherwise, I'd look for software that can deal with interruptions or slicing up the archive (or the image of the archive) into smaller pieces and upload those.

Finally, if you go the disk image route, consider turning on a modest amount of data redundancy (say 1:8) when you create the archive. That much data over a WAN is at risk of dropping a few bits here and there. Downside, it will make the whole archive 12% bigger.]]> https://forums.qrecall.com/posts/preList/935/3698.page https://forums.qrecall.com/posts/preList/935/3698.page GMT https://forums.qrecall.com/posts/preList/283/3472.page https://forums.qrecall.com/posts/preList/283/3472.page GMT
Updating to Version 2.1.8 did it! It´s just updating in the background. I am very impressed by the speed!
And by your support as well :-)

Thanks a lot.

Best from Europe

Nico]]> https://forums.qrecall.com/posts/preList/760/3335.page https://forums.qrecall.com/posts/preList/760/3335.page GMT