Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] master from borgbackup:master #86

Merged
merged 6 commits into from
Apr 11, 2025
Merged

[pull] master from borgbackup:master #86

merged 6 commits into from
Apr 11, 2025

Conversation

pull[bot]
Copy link

@pull pull bot commented Apr 11, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

Well, it's not totally removed, some code in Item, Archive and
borg transfer --from-borg1 needs to stay in place, so that we
can pick the CORRECT chunks list that is in .chunks_healthy
for all-zero-replacement-chunk-patched items when transferring
archives from borg1 to borg2 repos.

transfer: do not transfer replacement chunks, deal with missing chunks in other_repo

FUSE fs read: IOError or all-zero result
it now takes either:
- a list of ChunkListEntry namedtuples
- a list of chunk IDs [bytes]
preloading: always use raise_missing=False, because
the behaviour is defined at preloading time.

fetch_many: use get_many with raise_missing=False.
if get_many yields None instead of the expected chunk
cdata bytes, on-the-fly create an all-zero replacement
chunk of the correct size (if the size is known) and
emit an error msg about the missing chunk id / size.

note: for borg recreate with re-chunking this is a bit
unpretty, because it will transform a missing chunk into
a zero bytes range in the target file in the recreated
archive. it will emit an error message at recreate time,
but afterwards the recreated archive will not "know"
about the problem any more and will just have that
zero-patched file.
so guess borg recreate with re-chunking should better
only be used on repos that do not miss chunks.
Sometimes, usually for file content chunks, it makes sense to
generate all-zero replacement chunks on-the-fly.

But for e.g. an archive items metadata stream, this does not
make sense (because it wants to msgpack.unpack the data), so
we rather want None. In that case, we do not have the size
information anyway.
@pull pull bot added the ⤵️ pull label Apr 11, 2025
@pull pull bot merged commit e12b3bb into Mu-L:master Apr 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant