While this does not affect any behavior, it more accurately describes
the accessibility. Since abstract classes can only be instantiated by
an instance of a derived type, the constructors should at most have
protected access.
Rename 'DefaultExclude' to 'DefaultExcludes' (and the same for 'DefaultInclude').
Rename 'TemporaryFolders' to 'TemporaryFiles' to align with other groups ('CacheFiles', 'SystemFiles', etc.)
Added some more shorter aliases for groups, 'Sys', 'Tmp', etc.
This includes prefixing registry filters with '?:' (to match existing filters and make sure Duplicati respects them).
It also includes removing absolute drive paths ("C:\Program Files") when there is an identical wildcard drive path ("?:\Program Files").
This removes the documentation for default filters, and replaces it with documentation about filter groups (based in large part on what was already included with the initial filter groups change).
All documentation about the --include and --exclude parameters should now mention (at least in passing) the option to use filter groups.
This way, we can still add future filter groups for types of files that should be backed up (e.g., documents, pictures, etc.)
In light of this, I think the All group is somewhat problematic, since if we add new groups that are designed for inclusion, we don't want people accidentally excluding them (because they --exclude={all}).
This allows filter groups to be intermingled with other filters using the '{groupName}' syntax proposed by kenkendk.
It also means that when the filter that caused a file to be ignored is reported, it can report the name of the group, rather than a large and unreadable list of wildcard and regex patterns.
This is still missing several things (better documentation, removing the old --default-filters parameter, updating the UI), but should be another step in the right direction.
There might also might easily be other side effects that I haven't considered here that will need to be teased out and fixed.
Using GetAwaiter().GetResult() is similar to using Task.Result, but rethrows the original exception rather than wrapping it in an (unnecessary) AggregateException.
If one of these fields is accidentally reassigned, it's possible for
threads to be oblivious to an existing lock. By making the fields
readonly, we will be notified at compile-time if we inadvertently
redefine one of these fields.
Kenneth Hsu