syq vs rsync: I Benchmarked the New Copy Tool

syq hit Hacker News today and claims to be a better rsync. I cloned it, built it from source, and threw 5,000 small files and 1.3 GiB of random blobs at it. Result: it skips unchanged files in 0.02 seconds, survives a kill -9 mid-transfer and produces a byte-identical copy — but it also left 293 MB of stale partial files behind that nobody cleaned up. The copy is real. The auto-cleanup is not.

What syq Actually Is

syq (v0.5.2, MIT, Rust, 5 stars as of this morning) copies, reorganizes, and removes files locally or across machines. The pitch: resume interrupted transfers, send files to your laptop without an SSH server on it, and run commands on the receiving machine. It even speaks rsync-compatible syntax — syq rsync -av src/ server:dst/ — while using its own protocol underneath.

Building it was uneventful, which is itself a finding. cargo build --release, Rust 1.94 minimum on my 1.97 toolchain: 5m07s, one warning (unused_mut), done. The binary is a single self-contained file. No runtime dependencies, no config files.

cargo build --release   # 5m07s, 1 warning
syq --version           # syq 0.5.2

The Benchmark: syq vs cp on 1.3 GiB

Honest caveat first: this box has no rsync binary and no root to install one, so the comparison below is syq vs plain cp. rsync's rolling-checksum deltas are documented as unsupported by syq anyway — the README says so explicitly.

Two datasets: 5,000 files × 4 KiB in 50 directories (20 MB), and 20 files × 64 MiB (1.3 GiB). Same filesystem, page cache warm after first run. Every copy verified with diff -r — all byte-identical.

The headline isn't the fresh-copy win (~2× over cp, likely from parallel writes). It's the rerun. syq stats the destination and no-ops in 20 milliseconds on 1.3 GiB. That's what makes it a cron-job-friendly tool: rerunning a copy that changed nothing costs nothing. cp blindly rewrites everything, every time.

Kill -9 Mid-Transfer: Resume Works, Cleanup Doesn't

I started a 1.3 GiB copy and killed it with SIGKILL at 0.5 seconds. State at kill: 421 MB written, 2 files complete, 18 in-flight partials named .big1.syq-tmp.4vrxyvygpgjfnqnu — one hidden temp file per parallel worker.

syq: transferred 18 files (1.12 GiB), 128 MiB unchanged (2 files), 0 dirs created, 0:02 at 671 MiB/s

The resume run detected the 2 finished files as unchanged (128 MiB skipped), rewrote the 18 partial ones at 671 MiB/s, and the final destination diffed clean against the source. Resume is file-granular, not byte-granular — a half-written 64 MiB file gets restarted from zero. Fine for big files, wasteful for a 10 GB database dump that dies at 90%.

The rough edge: after the successful resume, 16 stale .syq-tmp files totaling 293 MB were still sitting in the destination. syq doesn't garbage-collect its own litter on completion. There is a dedicated command for it — syq clean-partials /path — and it worked, removing 16 entries instantly. But you have to know to run it. Fail your cron job silently enough times and you've silently doubled your disk usage.

The Feature Nobody Talks About: Capacity Preflight

I accidentally found this one. My test disk was 99% full, and instead of dying halfway through a 1.3 GiB copy like rsync does, syq refused to start:

syq: fresh destination capacity preflight failed: 1.25 GiB of logical
file data is required but only 330 MiB is available: No space left on device (os error 28)

It stats the source, sums the logical bytes, checks destination free space, and fails fast with the exact shortfall. That single error message saved me from a 1.3 GB cleanup job. This is the kind of boring defensive engineering rsync has never had, and it's worth more than the speed numbers.

Bottom Line

syq v0.5.2 is a genuinely well-engineered tool with one embarrassing gap. Unchanged-run detection at 0.02s, kill-and-resume that produces byte-identical results, a capacity preflight that fails fast — that's a better rsync for the sync-to-backup cron case. But it shipped resume support without cleaning up its own partial files, and the docs bury that under a separate clean-partials command. If you adopt it, add syq clean-partials to whatever schedule runs your copies. I couldn't test the SSH/remote path (no sshd on this box) — the local story is solid, the network story is still unverified by me.