process_file() ran process_file_chunks() inside `with backup_io('read')`.
That block is meant to guard reading the *source* file, but the source reads
are already guarded individually by backup_io_iter(). The outer wrapper also
caught add_chunk()'s (and maybe_checkpoint()'s) *repository* writes, so a
repository IO failure -- e.g. the repo running out of space -- was wrapped
into a per-file BackupOSError tagged "read". Borg then emitted misleading
"<path>: read: [Errno 28] No space left on device" warnings, pointlessly
retried the file, and only treated a critical repository error as a
non-critical per-file one, contrary to the BackupOSError docstring ("Any
unwrapped IO error is critical and aborts execution (for example repository
IO failure)").
In 1.4 the transactional repository still rolls the partial transaction back
on the eventual failure, so this is not data loss here (unlike borg2, where
it silently commits a corrupt archive). But the misclassification -- wrong
warning text and needless read-retries of a repository-full condition -- is
wrong regardless.
Drop the outer backup_io('read') wrapper. Source reads stay per-file
warnings (backup_io_iter is unchanged); repository OSErrors are now left
unwrapped and critical, aborting promptly with the correct error.
Verified on a space-limited macOS ramdisk: before, create emitted many
"read: [Errno 28]" retry warnings then rolled back; after, it aborts
immediately ("No space left on device, cleaning up partial transaction"),
commits no archive, and the repo stays consistent. Normal backups and
unreadable-source-file handling (per-file warning) are unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
When set, these override the hostname/username that is stored in newly
created archives and that is used for the {hostname}/{user} placeholders
(e.g. in archive names, prune --glob-archives, check). Useful to run borg
on host A but impersonate host B.
fqdn/hostid and the auto-detection are intentionally left untouched.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
msgpack does not support reusing an Unpacker instance after an unpacking
failure - a new instance must be created instead.
In the forced-delete path, item metadata was unpacked via "for item in
unpacker" with an "except (TypeError, ValueError)" handler. msgpack's
FormatError/StackError are ValueError subclasses, so a real unpacking
failure was caught there and the (now broken) unpacker kept being reused
for the following chunks, making them all fail too - leaking their chunk
references.
Restructure the loop to use next(unpacker) so each failure mode gets a
tight handler:
- StopIteration: buffer drained, feed next chunk
- msgpack.UnpackException: corruption; in forced mode replace the unpacker
with a fresh instance and skip the rest of the chunk
- TypeError/ValueError: only wraps Item processing (bad types yielded)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ProgressIndicatorBase installs a handler on the process-global
'borg.output.progress' logger and only removes it in __del__. In-process
(fork=False) command execution leaves this logger at level INFO /
propagate=False with lingering handlers, and that state leaks across tests.
When a later progress test runs, the "if not self.logger.handlers" guard
skips the stderr handler setup, so progress output goes to the logging
system instead of the stderr captured by capfd. Under xdist this surfaces
as order/distribution-dependent failures of the progress tests
(test_progress_percentage_*, test_extract_progress, test_progress_on,
test_check_usage, ...).
Add an autouse fixture that removes handlers and resets level/propagate on
the progress logger after each test. This also makes the intra-test
workaround in test_check_usage unnecessary (the progress logger level is
set per command run by _setup_implied_logging), so remove it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
macOS flags files whose content is stored in cloud storage (e.g. iCloud
Drive) and not present locally with SF_DATALESS. Reading such a file
triggers downloading its content.
With --exclude-dataless, borg create checks the flags (cheap, after
stat, before open) and skips such files/dirs, so backups do not force
a download of all cloud-stored data.
stat.SF_DATALESS is only available from Python 3.13 on, so we fall
back to the value from macOS' sys/stat.h on older Pythons.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Style the sidebar downloads line to align with the boxes above and the
table of contents below (padding 22px), with a horizontal separator both
between the search box and the downloads line and between the downloads
line and the table of contents.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace the multi-line "Download docs" block with a compact single line
"Downloads: PDF | HTML | ePub" placed right below the search box.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The resources doc page was removed long ago (#2088), but it was still
referenced in latex_appendices. This went unnoticed because PDF builds
were not enabled; enabling pdf surfaced it as a doctree KeyError.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Enable the pdf format on Read the Docs (the LaTeX build config already
existed in conf.py) and add a "Download docs" section to the sidebar that
links the offline formats (PDF, HTML zip, ...). The links are populated
from the Read the Docs addons data, reusing the same mechanism as the
version selector, so they are version-correct and hidden when unavailable.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- update to 'borg key change-passphrase' in env help
- remove outdated borg-change-passphrase man page from 2017
- remove outdated change-passphrase.rst.inc
This feature allows multiple repositories to share deduplication-relevant secrets (id_key and chunk_seed) while maintaining secure, independent encryption keys.
`borg key export-related-secrets <REPO> <SPATH>` to export the secrets to a JSON file.
`borg init --import-related-secrets <SPATH> <REPO>` to initialize a new repository using the secrets from the JSON file.
Both repositories must use the same chunk id algorithm (both HMAC-SHA256 or both BLAKE2b).
If you create related repositories with borg 1.4.x, you can later transfer their archives
to one or multiple related new borg2 repositories without breaking deduplication.
But please note that we might remove BLAKE2b support for new borg2 repos, see #8867,
so this might only work for HMAC-SHA256 in the end.
