Depending on the number of archives in a repository, the archive check part
of the check operation can take some time, so it should have a progress
indicator as well.
if we back up stdin / pipes / regular files (or devices with --read-special),
that may take longer, depending on the amount of content data (could be many GiBs).
usually borg announces file status AFTER backing up the file,
when the final status of the file is known.
with this change, borg announces a preliminary file status before
the content data is processed. if the file status changes afterwards,
e.g. due to an error, it will also announce that as final file status.
this is different default behaviour than in borg < 1.2:
default (numeric_owner=False) is to use the user/group name from the archive,
look up the local uid / gid and then use that for the FUSE fs.
when --numeric-owner is given (numeric_owner=True), then the uid/gid
from the archive is directly used (as it was the default behaviour in
borg < 1.2).
this was implemented like this (changing the default behaviour) to make
borg mount and borg extract behave more similar considering usage of
user/group numeric archived ids or archived names mapped to corresponding
numeric local system ids.
also, both now use the same function to get the uid/gid from the item.
fuse:
- add user and group name entries to default_dir
- also: set internal_dict(!) of new Item with data from Item.as_dict()
when given with borg create, borg will not get xattrs from input files (and thus, it will not archive xattrs).
when given with borg extract, borg will not read xattrs from archive and it will not set xattrs on extracted files.
when given with borg create, borg will not get ACLs from input files (and thus, it will not archive ACLs).
when given with borg extract, borg will not read ACLs from archive and it will not set ACLs on extracted files.
A) the compaction code needs the shadow index only for this case:
segment A: PUT x, segment B: DEL x, with A < B (DEL shadows the PUT).
B) for the following case, we have no shadowing DEL (or rather: it does not matter,
because there is a PUT right after the DEL) and x is in the repo index,
thus the shadow_index is not needed for the special case in the compaction code:
segment A: PUT x, segment B: DEL x PUT x
see also PR #5636.
reverts f079a83fed
and clarifies the code by more comments.
we keep the code deduplication of 5f32b5666a
and just add a update_shadow_index param to make it not look like there was
something accidentally forgotten, which was the whole reason for the reverted
"fix".
The shadow_index should be in same state after both of these sequences
(let's assume that A is not in repo yet for simplicity, but it does not matter):
a) explicit delete: put(A), delete(A), put(A), resulting in: PUT A, DEL A, PUT A repo contents
b) implicit delete: put(A), put(A), resulting in: PUT A, DEL A, PUT A repo contents
