Feature Request: more flexible include-/excludepattern

[joeuser]

It would be nice to have more flexible patterns for in- and excludes.
As they are available on the comandline like [0-9] or [aDR] or [a-z] to match digits concrete characters or alle lowercase characters.
This are only examples.

*[0-9].* should match files like 'foo3.xxx', 'bar99.txt'
*[0-9][0-9].* should only match files like 'foo23.xxx', 'bar99.txt'

Usually this patterns are supported by the underlying operating system hence it should not be complicated to implement this by passing the patterns to the appropriate OS function.

Next step could be the use of regexp pattern for include-/exclude pattern.
The challenge is that file system wildcards and regexp are very different in their syntax.
It may be necessary to implement a switch(checkbox) to tell FreeFileSync which pattern style(syntax) it should look for.

[Plerry]

The use of RegEx like behavior in the FFS In- and Exclude Filter has been suggested before (see e.g. here). The counter arguments listed there do also still apply. Apart from the addition of the column character ":", filter rule definitions have not changed since then.

[joeuser]

Then it would be nice to have a translator that can translate a RegExp into a set of filter expressions that match the FFS-Rules. Just for convenience.

[Plerry]

Because RegExp is much more powerful than FFS's Include and Exclude Filter wildcards (but proportionally to exponentially more complex) it is obviously not possible to translate RegExp into (just) FFS's Filter rules.

As described in Example: Complex filter rules with exceptions a solution can often be found in using multiple left-right base folder pairs.
However, translating single left-right base folder pair's RegExp rules into multiple left-right pairs seems to be very use-case specific.

[joeuser]

It is a question of mathematics to find a solution for a translation from one language to another.
This is a problem of graph theory and graph transformation.
A problem that can be solved in principle, even if gaps or imprecisions have to be accepted.
However, these are rarely a problem because rarely do all the possibilities of a language have to be used.

Where there's a will, there's a way.
Where there is no will, there is an excuse.

[Plerry]

Like xCSxXenon also wrote:

Where there's a will, there's a way.

The source code is provided, start coding ¯\_(ツ)_/¯