Open netw0rk-noob opened 2 months ago
I'm not opposed to adding pattern but I am curious if the following works (haven't tried it):
if you exclude: /rootdir/*.bak
if you include: /rootdir/*/*.bak
I'm not exactly sure how to test that with borg directly, as it does not have an --include
flag itself. I tried the following commands, both excluded rootdir/subdir/testfile.bak
. To my understanding the first one should replicate the behaviour of the plugin when additionally specifying the .bak
files beneath the subdirectories of rootdir
as a backup target ("include"):
borg create --dry-run --list --exclude "test/*.bak" borg::test rootdir rootdir/*/*.bak
borg create --dry-run --list --exclude "test/*.bak" borg::test rootdir/*/*.bak
Just to further explain my usecase - the directory in question is a working directory where files which have yet to be worked with/on are stored. It has one subdirectory - lets call it done
- with several subfolders (a sorting structure) in its own, also in various path depths. I need to include all the .bak
files beneath/inside of that done
-directory, but dont want to backup the - mostly temporary - files in the root directory.
I wanted you to test in the plugin not the command line. I will just have to try it later.
given the following folder structure:
I'd like to accomplish a filter that excludes all
.bak
files from/rootdir/
, but not.bak
files from subdirs of/rootdir/
, likesubdir/
. Is there any possibillity to do that with the current plugin? I wasnt able to find one.When testing with
borg create --dry-run --list
I got that working using--pattern '- /rootdir/*.bak'
. This only excludes/rootdir/testfile.bak
but not/rootdir/subdir/testfile.bak
. I didnt manage to get to the same result using--exclude
which is used by the OMV plugin. When trying--exclude '/rootdir/*.bak'
, both/rootdir/testfile.bak
and/rootdir/subdir/testfile.bak
are excluded.Solutions which would solve this problem (if there is no way to solve it with the plugin in its current state):
--exclude
option with--pattern
option which would greatly increase flexibility regarding available patterns but would break existing rules since another default rule matching process (fm
vs.sh
) would be used.--pattern
rules additionally. Would probably be confusing to most users.