we do not trust the remote, so we are careful unpacking its responses.
the remote could return manipulated msgpack data that announces e.g.
a huge array or map or string. the local would then need to allocate huge
amounts of RAM in expectation of that data (no matter whether really
that much is coming or not).
by using limits in the Unpacker, a ValueError will be raised if unexpected
amounts of data shall get unpacked. memory DoS will be avoided.
# Conflicts:
# borg/archiver.py
# src/borg/archive.py
# src/borg/remote.py
# src/borg/repository.py
if there are too many deleted buckets (tombstones), hashtable performance goes down the drain.
in the worst case of 0 empty buckets and lots of tombstones, this results in full table scans for
new / unknown keys.
thus we make sure we always have a good amount of empty buckets.
hardcoded the encoding for reading it. while utf-8 is the default
encoding on many systems, it does not work everywhere.
and when it tries to decode with the ascii decoder, it fails.
Computer clocks are often not set very accurately set, but borg
assumes manifest timestamps are never going back in time.
Ensure that this is actually the case.
note: we also ignore the call's return value in _chunker.c.
both is harmless as the call not working does not cause incorrect function,
just worse performance due to constant flooding of the cache (as if we
would not issue the call).
if anything blows up in the middle of a (first) invocation of close_segment()
and an exception gets raised, it could happen that close_segment() gets called
again (e.g. in Repository.__del__ or elsewhere).
As the self._write_fd was set to None rather late, it would re-enter the if-block
then.
The new code gets the value of self._write_fd and also sets it to None in one tuple
assignment, so re-entrance does not happen.
Also, it uses try/finally to make sure the important parts (fd.close()) gets executed,
even if there are exceptions in the other parts.
somehow without these cpuid settings it does not work for everybody.
also nice if we can get away without the extensions pack, which is proprietary.
do not update iTunes, we just want the OS security / bugfix updates