Timeouts/max-alloc/temp-dir parity #295

Closed
opened 2026-09-15 19:33:35 +02:00 by TapTap · 1 comment
Owner

Audit findings.

  • --timeout: FastSync defaults to 30s socket / 60s poll and rejects --timeout=0; rsync defaults to 0 (disabled) and 0 disables.
  • --contimeout: default 10s (rsync 60s) and rejects 0.
  • --max-alloc=0 rejected; rsync accepts 0 as "no limit".
  • --temp-dir: FastSync restricts the scratch dir to under the receive root and aborts the transfer on EXDEV; rsync accepts any temp dir and falls back to a non-atomic copy.

Fix: align defaults/zero handling, or document explicitly in the rows.

Audit findings. - `--timeout`: FastSync defaults to 30s socket / 60s poll and rejects `--timeout=0`; rsync defaults to 0 (disabled) and `0` disables. - `--contimeout`: default 10s (rsync 60s) and rejects `0`. - `--max-alloc=0` rejected; rsync accepts 0 as "no limit". - `--temp-dir`: FastSync restricts the scratch dir to under the receive root and aborts the transfer on EXDEV; rsync accepts any temp dir and falls back to a non-atomic copy. Fix: align defaults/zero handling, or document explicitly in the rows.
TapTap added the needs-triage label 2026-09-15 19:33:35 +02:00
Author
Owner

Fixed. --timeout defaults to 0 (disabled) and accepts 0; --contimeout defaults to 60 and accepts 0; --max-alloc=0 means no limit; --temp-dir now falls back to a non-atomic copy on EXDEV. Confinement of the scratch dir to the receive root is a deliberate, documented divergence (sandboxing). Closing as completed.

Fixed. `--timeout` defaults to 0 (disabled) and accepts `0`; `--contimeout` defaults to 60 and accepts `0`; `--max-alloc=0` means no limit; `--temp-dir` now falls back to a non-atomic copy on EXDEV. Confinement of the scratch dir to the receive root is a deliberate, documented divergence (sandboxing). Closing as completed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: TapTap/FastSync#295