if the rebuilt index size matched the on-disk index size AND there
was a difference in e.g. 1 key, the old code only output the key/value
for one index, but not what is present in the other index.
we already had better code in the branch for different index sizes,
so just use that for both cases.
additionally we tell when the index size matches (new) because we
also tell if there is a mismatch.
at least it does not crash now when committing.
the question why the compact map points to a missing segment file
is not answered yet, there might be another problem...
The code used for error reporting crashes due to an invalid utf-8
sequence. Use errors='replace' to never crash there. Errors
are expected in input data when borg check is run.
if an old hints file gets converted to the new format and it
has entries referring to non-existent segment files, a crash
occurred.
with this code, the crash is avoided and the erroneous hints
entry is removed.
support platforms with no os.link, fixes#4901
if we don't have os.link, we just extract another copy instead of making a hardlink.
for that to work, we need to have (and keep) the chunks list in hardlink_masters.
Looks like the minimum requirement for correct operations
on ARMv6 in non-fixup mode is xxhash 0.7.2.
note: this does not compile due to the experimental stuff in xxh3.h.
the problem was that after a resize that was triggered by too few
empty buckets, the rebuilt new hash table had entries at different
positions than before, but the idx where to SET the entry was not
recomputed afterwards.
create: tell that "Calculating size" time and space needs are caused by --progress
It took me several days to figure out that `--progress` was the culprit to Borg being SIGKILL'd by the kernel, because of OOM, and because of I enabled progress option. This elaborates on what's the calculation for.
from https://borgbackup.readthedocs.io/en/stable/usage/general.html#date-and-time
Unless otherwise noted, we display local date and time.
Internally, we store and process date and time as UTC.
OK, that does not directly say something about --timestamp, but as the cli is also part of the user interface (as output is), this might mean that maybe not the test needs fixing, but our processing of that option.
But, the docs also say:
--timestamp TIMESTAMP
manually specify the archive creation date/time (UTC, yyyy-mm-ddThh:mm:ss format).
Alternatively, give a reference file/directory.
So, using UTC there is a documented feature, although it is different from output using localtime.
So, the test fix in this PR is correct according to the docs. \o/
The RepositoryCache used `os.statvfs` which is not available on Windows.
`shutil.disk_usage` provides the same information but in a cross platform way.
changes:
- changed --prefix default to None (was: ''), so we can check using
"is not None" to determine when --prefix has been given.
- the previous check for --prefix being used was just for a truthy
value, so using --prefix='' was not really supported, but happened to
behave the same as the default processing anyway.
- argparse python stdlib code seems to have a bug when processing an
option like --prefix='--', args.prefix will be [] in that case (should
be '--'). With previous code this behaved like no prefix given ([] value
is not truthy). Now, as we check for "is not None", it will try to
process that value but blow up with a TypeError as it can't do [] + '*'.
This is a bit unpretty end, but at least borg prune won't delete all
your archives and it will be a reminder that argparse is broken.
- for borg check --repository-only, we also check for --glob-archives
not being used and give the warning otherwise.
we create the hardlink to be able to secure erase the old config file.
if we can't do that because there is just a problem with hardlinks not
working, the old config will be just overwritten normally (not secure
erased). the user will get a warning in that case, but other than that,
the overall borg operation will succeed.
if there is a bigger problem (like a general lack of permissions or a
general issue with the underlying fs), subsequent operations will fail.
