Skip to content

Add log-format alias and no-checksum toggle#2161

Merged
oferchen merged 1 commit into
masterfrom
align-oc-rsync-with-upstream-rsync-3.4.1
Nov 16, 2025
Merged

Add log-format alias and no-checksum toggle#2161
oferchen merged 1 commit into
masterfrom
align-oc-rsync-with-upstream-rsync-3.4.1

Conversation

@oferchen
Copy link
Copy Markdown
Owner

Summary

  • expose --log-format as a visible alias for --out-format and add the --no-checksum toggle to the CLI
  • track checksum selection as a tri-state flag throughout CLI parsing, configuration, and fallback plumbing so --no-checksum is forwarded to the legacy binary
  • add regression tests that cover the new alias, CLI parsing, and fallback argument generation

Testing

  • cargo test -p cli parse_args_accepts_log_format_alias -- --nocapture
  • cargo test -p cli checksum_flag_can_be_disabled -- --nocapture
  • cargo test -p core remote_fallback_forwards_no_checksum_toggle -- --nocapture

Codex Task

@oferchen oferchen merged commit 68497a3 into master Nov 16, 2025
6 checks passed
@oferchen oferchen deleted the align-oc-rsync-with-upstream-rsync-3.4.1 branch November 16, 2025 08:56
oferchen added a commit that referenced this pull request May 16, 2026
…#4113)

NONREG is part of upstream rsync's info_verbosity[0] table
(options.c:240), so the flag is enabled by default at level 1 even
without -v. Upstream emits "skipping non-regular file \"%s\"" from
generator.c:1687 under INFO_GTE(NONREG, 1) whenever a non-regular
source falls through the regular handlers.

oc-rsync had the flag wired through CLI parsing and the level table
(nonreg=1 at all -v levels) but no producer. The audit doc flagged
this as "Stub" with the note: "We do not emit a 'skipping
non-regular file' message anywhere; the gate exists in parsing but
no producer."

Funnel the emission through CopyContext::record_skipped_non_regular,
which is the single point all local-copy non-regular skip paths
converge on (symlink fall-through, FIFO without --specials, device
without --devices, recursive walk SkipNonRegular). The info_log!
macro gates formatting behind info_gte(Nonreg, 1) so the call is a
no-op when the flag is disabled via --info=nononreg.

The verbose listing path (emit_verbose) still renders the same
wording to stdout when -v is set, so user-facing output at -v is
unchanged. The new emission additionally feeds the diagnostic queue
at verbosity 0, matching upstream's default-on behaviour.

Two new tests assert byte-for-byte upstream wording and confirm the
emission is gated by info.nonreg. The existing
verbose_transfer_reports_skipped_specials test was loosened to
accept the notice on either stdout (legacy path) or stderr
(diagnostic queue) so it tolerates the additional emission point.
The audit doc rolls NONREG from Stub to Match.

Closes #2161.
oferchen added a commit that referenced this pull request May 18, 2026
…#4113)

NONREG is part of upstream rsync's info_verbosity[0] table
(options.c:240), so the flag is enabled by default at level 1 even
without -v. Upstream emits "skipping non-regular file \"%s\"" from
generator.c:1687 under INFO_GTE(NONREG, 1) whenever a non-regular
source falls through the regular handlers.

oc-rsync had the flag wired through CLI parsing and the level table
(nonreg=1 at all -v levels) but no producer. The audit doc flagged
this as "Stub" with the note: "We do not emit a 'skipping
non-regular file' message anywhere; the gate exists in parsing but
no producer."

Funnel the emission through CopyContext::record_skipped_non_regular,
which is the single point all local-copy non-regular skip paths
converge on (symlink fall-through, FIFO without --specials, device
without --devices, recursive walk SkipNonRegular). The info_log!
macro gates formatting behind info_gte(Nonreg, 1) so the call is a
no-op when the flag is disabled via --info=nononreg.

The verbose listing path (emit_verbose) still renders the same
wording to stdout when -v is set, so user-facing output at -v is
unchanged. The new emission additionally feeds the diagnostic queue
at verbosity 0, matching upstream's default-on behaviour.

Two new tests assert byte-for-byte upstream wording and confirm the
emission is gated by info.nonreg. The existing
verbose_transfer_reports_skipped_specials test was loosened to
accept the notice on either stdout (legacy path) or stderr
(diagnostic queue) so it tolerates the additional emission point.
The audit doc rolls NONREG from Stub to Match.

Closes #2161.
oferchen added a commit that referenced this pull request May 18, 2026
…#4113)

NONREG is part of upstream rsync's info_verbosity[0] table
(options.c:240), so the flag is enabled by default at level 1 even
without -v. Upstream emits "skipping non-regular file \"%s\"" from
generator.c:1687 under INFO_GTE(NONREG, 1) whenever a non-regular
source falls through the regular handlers.

oc-rsync had the flag wired through CLI parsing and the level table
(nonreg=1 at all -v levels) but no producer. The audit doc flagged
this as "Stub" with the note: "We do not emit a 'skipping
non-regular file' message anywhere; the gate exists in parsing but
no producer."

Funnel the emission through CopyContext::record_skipped_non_regular,
which is the single point all local-copy non-regular skip paths
converge on (symlink fall-through, FIFO without --specials, device
without --devices, recursive walk SkipNonRegular). The info_log!
macro gates formatting behind info_gte(Nonreg, 1) so the call is a
no-op when the flag is disabled via --info=nononreg.

The verbose listing path (emit_verbose) still renders the same
wording to stdout when -v is set, so user-facing output at -v is
unchanged. The new emission additionally feeds the diagnostic queue
at verbosity 0, matching upstream's default-on behaviour.

Two new tests assert byte-for-byte upstream wording and confirm the
emission is gated by info.nonreg. The existing
verbose_transfer_reports_skipped_specials test was loosened to
accept the notice on either stdout (legacy path) or stderr
(diagnostic queue) so it tolerates the additional emission point.
The audit doc rolls NONREG from Stub to Match.

Closes #2161.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant