This change implements the functionality requested in issue #361:
extracting files with a given extension. It does so by permitting
patterns to be used instead plain prefix paths. The pattern styles
supported are the same as for exclusions.
The “extract” command supports extracting all files underneath a given
set of prefix paths. The forthcoming support for extracting files using
a pattern (i.e. only files ending in “.zip”) requires the introduction
of path prefixes as a third pattern style, making it also available for
exclusions.
A function to parse pattern specifications was introduced in commit
2bafece. Since then it had a hardcoded default style of “fm”, meaning
fnmatch. With the forthcoming support for extracting files using
patterns this default style must be more flexible.
The utility functions “adjust_patterns” and “exclude_path” produce
respectively use a standard list object containing pattern objects.
With the forthcoming introduction of patterns for filtering files
to be extracted it's better to move the logic of these classes into
a single class.
The wrapper allows adding any number of patterns to an internal list
together with a value to be returned if a match function finds that
one of the patterns matches. A fallback value is returned otherwise.
- Stop using “adjust_pattern” and “exclude_path” as they're utility
functions not relevant to testing pattern classes
- Cover a few more cases, especially with more than one path separator
and relative paths
- At least one dedicated test function for each pattern style as opposed
to a single, big test mixing styles
- Use positive instead of negative matching (i.e. the expected list of
resulting items is a list of items matching a pattern)
also: make check in Lock.close more precise, check for "is not None".
note: a lot of blocks were just indented to be under the "with" statement,
in one case a block had to be moved into a function.
there is no such method in the code.
we use "check" method to repair the repo, so maybe this was left over
from a time when repair was separate from check.
the problem was that the borg process removed its own shared lock when upgrading it to an exclusive lock.
this is fine if we get the exclusive lock, but if we don't, we must re-add our shared lock.
this fixes the KeyError in locking.py:217
