On windows os.open does not work for directories.
If borg tries to open an directory on windows, None is returned
as file descriptor. The archive and archiver where adjusted to
handle the case if a file descriptor is None.
- Created a batch file to build borg on windows
- Adjusted setup.py to be runnable on windows and build the windows
extension
- Extracted the free space check to a function in the platform module
- Created the minimal needed (dummy) functions for the windows platform
module
if the remote server does not support the dict-based argument passing
yet (e.g. when accidentally using borg 0.29 on rsync.net), the GET rpc
call argument list failed to generate if the command currently being
processed was not a GET also.
note: rsync.net has a more recent borg as "borg1".
this happened because the user had pytest5 installed somehow,
although it is incompatible with python 3.4:
# python3 /usr/local/bin/borg --version
Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/borg/archiver.py", line 81, in <module>
from .selftest import selftest
File "/usr/local/lib/python3.4/dist-packages/borg/selftest.py", line 21, in <module>
from .testsuite.hashindex import HashIndexDataTestCase, HashIndexRefcountingTestCase, HashIndexTestCase
File "/usr/local/lib/python3.4/dist-packages/borg/testsuite/__init__.py", line 29, in <module>
from pytest import raises
File "/usr/local/lib/python3.4/dist-packages/pytest.py", line 6, in <module>
from _pytest.assertion import register_assert_rewrite
File "/usr/local/lib/python3.4/dist-packages/_pytest/assertion/__init__.py", line 6, in <module>
from _pytest.assertion import rewrite
File "/usr/local/lib/python3.4/dist-packages/_pytest/assertion/rewrite.py", line 443, in <module>
ast.MatMult: "@",
AttributeError: 'module' object has no attribute 'MatMult'
This test assumed that zlib would always produce the same output for a
given input, and that assumption has proven incorrect. It rested on
zlib never improving. The zlib shipped in Clear Linux has algorithm
improvements, which caused this test to break.
This patch instead decompresses the expected value and compares that.
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
The build process can be controlled via environment variables
similar to other bundled libraries in borgbackup. The main difference
is probably that upstream does not provide a pkgconfig file for
xxhash.
Therefore borg will probably fail to detect the system-provided
version by default (tested on Fedora, seems like Debian and Ubuntu
do not ship a pkgconfig file either). I kept the pkgconfig lookup
code anyway to keep the code as similar as possible to
"setup_compress.py"/"setup_crypto.py".
Setting BORG_LIBXXHASH_PREFIX=/usr helps borg to detect xxhash
on my system (Fedora). You can force the use of the bundled
version of xxhash by setting BORG_USE_BUNDLED_XXHASH=1.
compact / config: yes, should be optional (can get repo from BORG_REPO
environment variable)
some debug commands: rather not, have non-optional addtl. posargs
if the tests use a pure-python msgpack, 1 test which is specifically
made for that, will fail. esp. for linux distribution packages, this
will still point to the problem (that the msgpack package is not built
or installed correctly).
This is a forward port of 24118459c6
the check checks whether follow_symlinks=False is supported, which
requires that the glibc is recent enough / python was compiled
for a recent enough glibc. follow_symlinks=False is only used for borg
create and extract, but not needed for borg serve.
thus, this makes it possible to run "borg serve" even on a bit older
servers. be careful, due to the presence of this check on the server
side until now, older server systems are not really much tested.
archives with borg 1.2 metadata: quick, we have precomputed size data
in archive metadata and just need to sum up for all archives.
archives without borg 1.2 metadata: expensive, need to read all
archives' items metadata streams and sum up for all items.
if the repo config is not there, we definitely have a invalid repo.
for other problems (like permission issues), we'll just let it blow
up with a traceback, so the user can see what the precise problem is.
