Skip to content

Sync upstream main (647d00f6) - #6

Open
justin-russell wants to merge 12 commits into
mainfrom
sync/upstream-647d00f6
Open

justin-russell wants to merge 12 commits into
mainfrom
sync/upstream-647d00f6

Conversation

@justin-russell

Copy link
Copy Markdown

Clean merge of 11 upstream commit(s) up to 647d00f6adde3c77836dccd9bbac61a7817e0591 (upstream main (647d00f)). Opened by upstream-merge-cron.sh.

justin-russell and others added 11 commits August 26, 2026 07:23
`rustic_core` does not compile for `aarch64-apple-ios`. In
`crates/core/src/backend/local_destination.rs`, the `NodeType::Dev` and
`NodeType::Chardev` branches convert the stored device id to the `dev_t`
that `nix::sys::stat::mknod` expects. On Darwin `dev_t` is `i32`, so the
code has a gate that does `i32::try_from(*device)` for `macos` and
`openbsd`, and passes the `u64` through everywhere else.

iOS is Darwin too — same libc, same `i32` `dev_t` — but the gate only
names `macos`. On iOS the crate takes the pass-through path and hands a
`u64` to a function wanting `i32`:

```
error[E0308]: mismatched types
  --> crates/core/src/backend/local_destination.rs:715:65
    mknod(&filename, SFlag::S_IFCHR, Mode::empty(), device)
                                                    ^^^^^^ expected `i32`, found `u64`
```

This adds `target_os = "ios"` beside `target_os = "macos"` in the three
places that gate appears: the `DeviceIdConversionFailed` error variant's
`cfg` (which would otherwise be undefined on iOS), and the two
conversion sites. No behaviour changes on any currently compiling
target; the `all(target_os = "android", target_pointer_width = "32")`
arm is untouched.

The path is not reachable at runtime for a sandboxed iOS app (it
restores no block or character devices), but it is compiled regardless,
so the crate does not build for the target at all — and a `cargo check`
on macOS does not reveal it, because the gate that is wrong is the one
macOS does not take.

Verified with a crate depending on `rustic_core` and `rustic_backend`
(`rest` only, no `opendal`): `aarch64-apple-ios` and
`aarch64-apple-ios-sim` both compile after this, `aarch64-apple-darwin`
still compiles, and `zstd-sys` and `ring` cross-compile for iOS without
complaint.

If you'd rather cover the whole Apple family at once (tvOS, watchOS and
visionOS share the same `dev_t`), `target_vendor = "apple"` in place of
the two `target_os` entries would do it — I kept this to the narrowest
change, but happy to switch.

Co-authored-by: Josh <jbbritt774@gmail.com>
## Summary

- update root and published core README examples to use Credentials
- use the current init and open signatures in all four examples
- repair the snapshot example code fence

Fixes rustic-rs#502

## Validation

- cargo test -p rustic_core --doc --locked
- cargo fmt --check
- git diff --check

Co-authored-by: Magrathean UK <magrathean-uk@users.noreply.github.com>
## Summary

- retain the failing path when canonicalization fails
- include it in the user-facing error and regression test

Fixes rustic-rs#429

## Validation

- cargo test -p rustic_core path_list_sanitize_error_includes_path
--locked
- cargo check -p rustic_core --locked
- cargo fmt --check

Co-authored-by: Magrathean UK <magrathean-uk@users.noreply.github.com>
Co-authored-by: Magrathean UK <magrathean-uk@users.noreply.github.com>
## Summary

- preserve the atomic replacement path
- run post-delete after a successful config replacement and before
post-create
- check for an existing destination only for config writes with a
configured post-delete hook
- cover the create, overwrite, delete, create hook order

Related: rustic-rs/rustic#1417

## Validation

- cargo test --locked -p rustic_backend: 33 passed; doc tests passed
- cargo clippy -p rustic_backend --tests --locked -- -D warnings
- cargo fmt --all -- --check
- git diff --check

---------

Co-authored-by: Magrathean UK <magrathean-uk@users.noreply.github.com>
Co-authored-by: aawsome <37850842+aawsome@users.noreply.github.com>
## Summary

- stop tree-loading workers when the consumer has already exited
- handle a closed output channel inline without panicking

Related: rustic-rs/rustic#1877, rustic-rs/rustic#1790,
rustic-rs/rustic#1437, rustic-rs/rustic#1400

## Validation

- cargo test --locked -p rustic_core --lib: 168 passed
- cargo clippy -p rustic_core --lib --tests --locked -- -D warnings
- cargo fmt --all -- --check
- git diff --check

---------

Co-authored-by: Magrathean UK <magrathean-uk@users.noreply.github.com>
)

This PR introduces a reqwest client which is used by both the rest and
the opendal backend (for http-based backend access).

Furthermore it adds some options to fine-tune this client:
- `http-insecure-tls` -> allows to use self-signed certificates
- `http-referer` -> allows to configure whether a Referer header is used
- `timeout` (new for opendal) -> allow to configure the timeout for a
single http request
- `cacert` (new for opendal) -> allows to read and use a root
certificate from a local file
- `tls-client-cert` (new for opendal) -> allows to read and use a client
certificate from a local file.

closes rustic-rs#555
closes rustic-rs/rustic#1895

This is a breaking change as `RestBackend::new` now takes the options as
`BTreeMap<String,String>` instead as accepting any iterator.
## Summary

- replace OpenDAL's default retry interceptor with a compact one-line
warning
- keep the same information (error, delay, operation, attempt) without
dumping the `Debug` context tree
- match the REST backend style: `Error {err} at {duration:?}, retrying
...`

## Why

Temporary backend errors such as B2 `connection closed before message
completed` are already retried. The default interceptor formats the
error with `{:?}`, which prints a multi-line Context/Source dump and
overwrites progress output. OpenDAL's `Display` form is already a single
line.

## Validation

- `cargo test -p rustic_backend --lib opendal`
- `cargo clippy -p rustic_backend --lib -- -D warnings`

A companion rustic CLI PR captures console logs while the TUI owns the
terminal so remaining log output cannot overwrite the progress popup.
## Summary

- count source scan and archival errors instead of only logging them
- report those errors through `Progress::error` (`scan` / `archival`)
- attach the source path on local walk/open failures
- expose a `SnapshotSummary.error_count` for the just-completed backup

## Why

restic returns exit code 3 when some source files cannot be read, and
still creates a snapshot of the remaining files. rustic currently
ignores those errors and exits 0, so automation cannot detect incomplete
backups.

## Validation

- `cargo test --test integration
test_backup_unreadable_file_sets_error_count` (unix; chmod 000 file)
- `cargo fmt --all`
- clippy on the changed files

A companion rustic CLI PR will use `error_count` to exit 3 and emit
restic-compatible JSON `error` / `exit_error` messages.

---------

Co-authored-by: Alexander Weiss <alex@weissfam.de>
Co-authored-by: aawsome <37850842+aawsome@users.noreply.github.com>
Merging subpaths leads to some errors and is not necessary. Actually it
should be users' choice which paths are backup'ed.

closes rustic-rs/rustic#1397
@justin-russell
justin-russell force-pushed the sync/upstream-647d00f6 branch 7 times, most recently from 0216dd5 to 28f84f7 Compare September 14, 2026 07:47
@justin-russell
justin-russell force-pushed the sync/upstream-647d00f6 branch 7 times, most recently from 80a9e00 to fd2da59 Compare September 21, 2026 07:47
@justin-russell
justin-russell force-pushed the sync/upstream-647d00f6 branch 5 times, most recently from cb981fa to 03a9c39 Compare September 26, 2026 07:47
@justin-russell
justin-russell force-pushed the sync/upstream-647d00f6 branch 8 times, most recently from 2d1b2bc to 311a556 Compare October 4, 2026 07:47
@justin-russell
justin-russell force-pushed the sync/upstream-647d00f6 branch 5 times, most recently from a01319b to 036fbf3 Compare October 9, 2026 07:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants