In the graphical interface, if the user add a filter excluding/including files contains strings, duplicati will not correctly specify the command line argument. And then it will throw an error saying that the bracket is not closed.
Reproducing the bug
Go to the command line interface and edit a configuration of a backup.
In the third step add a filter (and edit as a list) excluding files contains a certain pattern.
Save the configuration and run the backup. You will see the error.
Cause of the bug
In Windows, to exclude a file we need to use [.*foobar.*[^\\]]. If there’s only one single \, duplicati will throw an error saying the bracket is not close. This is because \] would be translated into the charater ] instead of the closing bracket. Therefore we have to put two slash where the first one specifies that the second slash is not an escape character but the \ character itself.
Somehow when editing the filter as a list, instead of edit it as text, in the GUI, duplicati will not make the exclusion argument right. After you typed in the pattern you want to me matched, and then switch to “edit as text”, you would find the command line argument is wrongly specified, which has only one slash rather than two.
I suspect the bug is fromsuffix: '.*[^!]]', where a Negative Character Group: [^] means to not match something ending with the separator that indicates a directory, according to Duplicati Syntax documentation.
Character Escapes start with backslash, so Windows directory separator backslash needs its own backslash whereas I have a suspicion that this bug would not happen on Linux. A forward slash is not special to an RE, however a backslash before a non-special character just gives the character, so “\!” in source “should” work.
Web UI workaround is to avoid “Exclude files whose name contain” in favor of something more do-it-yourself, for example “Exclude expression” or “Exclude regular expression”, then go read the documentation carefully. Checking in Commandline that the web UI did what you wanted might also be helpful until you’re used to this.
Being new at filtering, I’m both impressed and concerned by all the semantics –include and –exclude accept.
Web UI helps to cover some of that syntax complexity, however in this case it seems it didn’t get it quite right.
Just as you said, this issue is only present on Windows platform. The official documentation mentioned the difference of filter syntax between *nix and Windows, and you’re exactly right that the problem results from the Windows platform directory separator, i.e. backslash, conflicting with character escape, also backslash.