Choose rclone when the workflow needs its explicit copy, check and sync commands and may later involve a supported storage backend. Choose the macOS rsync (openrsync) executable tested here for a local folder-copy workflow that already depends on its command-line behavior. For verified copies, the crucial decision is the equality policy: matching file size and modification time do not prove matching contents.
Our synthetic local fixture gave both tools a destination file with different contents but the same size and timestamp. Both default copy commands left that file unchanged. Adding checksum comparison repaired it in both cases. A second result mattered just as much: rclone’s ordinary check reported a destination-only file as a difference, while check –one-way accepted the same folder. Those commands answer different questions.
Compare the job, then the flags
| Tool | Tested copy | Content comparison | Destination-only file |
|---|---|---|---|
| rclone | copy source destination | copy –checksum repaired the equal-metadata mismatch | Retained by copy; check failed; check –one-way passed |
| macOS rsync (openrsync) | rsync -a source/ destination/ | -ac repaired the equal-metadata mismatch | Retained without –delete; deletion previewed only |
rclone
rclone’s copy command copies source contents without making the destination an exact mirror. We tested rclone 1.75.2 against its local filesystem backend. We did not configure or authenticate any cloud remote.
The default copy added our missing manifest.txt but left the already-present invoice.csv alone. Its size and timestamp matched the source even though its contents did not. With –checksum, rclone replaced it with the source contents. That extra content comparison has I/O implications, but we did not measure its cost or claim a throughput result.
The separate check command made the acceptance policy visible. After the corrected copy, ordinary check returned exit code 1 because orphan.txt existed only at the destination. check –one-way returned 0: both source files were present and matched, while the extra destination file was allowed. Pick the policy intentionally before interpreting an exit code as success or failure.
macOS rsync (openrsync)
The executable at /usr/bin/rsync on our tested macOS system identifies itself as openrsync, protocol version 29, compatible with rsync 2.6.9. It is not an upstream rsync 3.x build. The openrsync manual explains its copy-oriented interface and checksum option; our conclusions about execution apply to this macOS binary, not every program named rsync.
We ran -a with a trailing slash on the source, copying its contents into the destination. The equal-size/equal-time invoice was skipped. Repeating with -ac replaced it. The extra destination file remained in both runs because we had not requested deletion.
This is sufficient for the narrow choice of a local, repeatable command whose behavior you can verify on the actual machine. It does not compare SSH transfers, incremental network algorithms, newer rsync features or all filesystem metadata. If you install another rsync build, record its version and rerun the fixture rather than inheriting this result.
The actual mismatch and commands
The source invoice.csv contained ACME,100 followed by a newline. The destination contained ACME,900 followed by a newline. Both files were nine bytes and both modification times were set to Unix timestamp 1700000000. The source also contained manifest.txt; the destination also contained orphan.txt. All files were synthetic scratch data.
The original mismatching SHA-256 prefixes were 1ed3d3f9258d for the source and da5e24f731c8 for the destination. After either default copy, the destination still had the latter hash. After the corresponding checksum copy it matched the source hash. We computed these hashes independently for the evidence record; that does not mean either tool used SHA-256 internally.
# Run only in disposable fixture folders.
# Recreate the mismatching destination before each tool's trial.
rsync -a source/ destination/
rsync -ac source/ destination/
rclone copy source destination
rclone copy --checksum source destination
rclone check source destination
# Exit 1: orphan.txt exists only at destination.
rclone check --one-way source destination
# Exit 0: both source files match; destination extras allowed.Both tools’ default copies also transferred manifest.txt, so the run looked productive while the mismatching invoice remained. This is why checking that a command ran and copied something is weaker than checking the intended end state.
Deletion previews are a separate decision
We inspected rclone sync --dry-run -v source destination and rsync -acn --delete -v source/ destination/. Both previews identified orphan.txt for deletion, and subsequent filesystem readback confirmed that it still existed. No live deletion command was executed. rclone’s sync documentation describes destination changes; keep a reviewed dry run when a mirror is actually the desired state.
For a retained business archive, source coverage may be enough and destination extras may be intentional. For an exact delivery package, extras may violate the contract. A checksum match proves the compared bytes match under that check; it does not prove the source is the right business version, that permissions are appropriate, or that a restore will work.
Our recommendation is rclone when its explicit check policy or a subsequently verified backend is useful; use the tested macOS rsync when a local copy command is sufficient and its flags are familiar. Both passed the checksum repair. Choose retention and verification rules before choosing the command.
rclone publishes its MIT license. This article has no hosted subscription or storage-price comparison; local software, a storage provider and managed support are separate costs. For recovery products see computer backup software, and for the destination service see object storage services. A successful file copy is not a backup restore test.
Methodology and limitations
Toolverly Editorial executed these commands on 17 October 2026 on macOS 26.6.2 arm64, rclone 1.75.2 and the system openrsync-compatible executable described above. We reset independent destinations before the two default-copy trials, then ran checksum copies and read back filenames, contents and hashes. Exact and one-way rclone checks were run after repair. Source documentation was checked the same day.
We did not test remote storage, SSH, network throughput, cloud hash availability, permissions preservation or recovery. Backend checksum support must be verified separately. Deletion was previewed only. This local functional fixture did not access or copy a production site and did not create a backup.
By Toolverly Editorial. AI assistance was used to prepare code, research and prose; the local examples were executed and their outputs reviewed before publication.
Photo by Kevin Ache on Unsplash. Read about our publication or send a correction.