wrap msgpack to avoid future upstream api changes making troubles
or that we would have to globally spoil our code with extra params.
make sure the packing is always with use_bin_type=False,
thus generating "old" msgpack format (as borg always did) from
bytes objects.
make sure the unpacking is always with raw=True,
thus generating bytes objects.
note:
safe unicode encoding/decoding for some kinds of data types is done in Item
class (see item.pyx), so it is enough if we care for bytes objects on the
msgpack level.
also wrap exception handling, so borg code can catch msgpack specific
exceptions even if the upstream msgpack code raises way too generic
exceptions typed Exception, TypeError or ValueError.
We use own Exception classes for this, upstream classes are deprecated
most of the files created via self.create_test_files() are not needed.
the only one is the empty file, so just create it here.
also: move repo init to after test file creation.
if we are recursing an explicitly excluded directory, we are only
looking for explicitly included items, but we do not need to archive
tagged directories or the tag files themselves - they are all excluded
by the explicit exclusion already.
for performance reasons, we still determine whether a directory is
tagged and if it is, we do not recurse into it as there can't be any
included items in there.
It causes problems with the new caching in the py37 logger module.
Removing loggerDict.clear() fixes this and makes the tests work again.
Also, it does not seem to have any negative effect, neither on py36
nor on py37.
See also: https://bugs.python.org/issue34269
in some cases the value of a new parameter does not really matter,
as long as it works / there is no malfunction.
without this change, a new borg client could not commit to an old
borg server (and would fail late when trying to commit):
- when using compact=False as it does at most places
- when using cleanup_commits=True as a user might trigger by running
borg compact --cleanup-commits
we never want a borg commit "fail late", leaving the repo in a state
with uncommitted data, thus the server shall just commit, no matter
how it handles compaction or whether it can do the cleanup.
specialcase deleting / writing the manifest to be in a separate, new
segment file, so that when we supersede and compact it later, less
segment data has to be shuffled around - compaction can then just
delete this segment file and that's all.
