As the reporter for #753 who already lost data to a prune that was effectively matching all (due to the issue reported in #753), I would prefer that prune's filter not be overly aggressive by…
And yes, apparently the grand purge of all of my older backups took place sometime around March of this year, I just didn't notice it until now (at least according to data from my off-site backup…
Sorry for not reporting back. Yeah, the patch I developed is working properly, and it ended up being a one or two liner (plus adding an entry to the configuration), I forget exactly right now. Effectively, I just change the directory to the one specified in the configuration file if that configuration is present, before beginning to execute borg commands.
Somehow I missed your comment (my browser probably updated the page once I commented).
I was able to hack in the ability to change the current working directory per configuration file, by adding a new field to location, and in run_configuration add a check that if that field is specified, just set the application's working directory to that value.
Alright, after reading a bit more about how everything is implemented, and how Python handles subprocess current working directory, I ran a test. If I run borgmatic from the root of my shared drive, the current working directory is passed to all subprocesses, and the relative path in the configuration file (location.repositories) works as expected. I suppose this is a workaround, and I might be able to get the effect I want using cron by chaining a cd and the borgmatic invocation. It would still be nice to be able to specify the current working directory (unless there's a better way to do what I tried to describe earlier).