rsync -c (--checksum): compare file contents instead of size and time
- tool
- rsync
- command
- rsync
- flag
- -c, --checksum
- default
- off: the quick check compares size and modification time only
By default rsync decides whether a file needs updating with a quick check: if size and modification time are the same on both sides, the file is skipped. rsync -c (--checksum) replaces that decision with a content check: for every file whose size matches, both sides compute a 128-bit checksum and the file is transferred only if the checksums differ. Use it when timestamps are not trustworthy, for example after copying with a tool that did not preserve them, or when a file may have changed without its size or mtime changing.
Syntax
rsync -ac src/ dest/ # archive mode, compare by content
rsync -acn --itemize-changes src/ host:dest/ # preview which files differ by content
rsync -a --checksum src/ dest/ # long formCombining -c with -n (dry run) and --itemize-changes is a cheap way to list files whose contents differ between two trees without copying anything (see rsync -n).
How rsync decides what to transfer
| Option | A file is transferred when | Cost |
|---|---|---|
| (default quick check) | size or modification time differs | Only metadata is read |
| -c, --checksum | size differs, or size matches and the checksum differs | Both sides read every same-size file |
| --size-only | size differs (times are ignored) | Only metadata; misses edits that keep the size |
| -I, --ignore-times | always (quick check disabled) | Every file is updated |
| --modify-window=1 | times differ by more than 1 second | Useful for FAT file systems with 2-second resolution |
What changes when you set it
- Disk I/O goes up sharply. The sender computes checksums while it builds the file list, before any data moves; the receiver computes them while scanning for changed files. On a tree of many gigabytes the first output can take minutes.
- Timestamps still matter with -a. If contents match but the mtime differs, rsync does not transfer the file, but
-a(which includes-t) still updates the destination's modification time, so a later run without-cis fast again. - The algorithm is negotiated. The checksum is chosen automatically between client and server;
--checksum-choice(alias--cc) or the environment variable described in that option overrides it.
Pitfalls
- Do not add
-cto every cron backup by habit: it multiplies run time and wears disks, while the quick check is correct whenever mtimes are preserved (-apreserves them). - Clock skew between machines does not affect the quick check, because rsync compares the stored modification times, not the current clock. Use
-cfor genuinely unreliable timestamps, not for time zone worries. - With
--delete(see rsync --delete)-conly changes which existing files are updated; deletion still depends on names alone. - On a FAT or exFAT destination, try
--modify-window=1before reaching for-c; it fixes the usual "everything is copied again" problem at a fraction of the cost.
FAQ
Does rsync verify files after copying them even without -c?
Yes. rsync always checks a whole-file checksum of every file it transfers, generated while the file is sent. -c only changes the decision before the transfer, whether a file needs updating at all.
Why does rsync -c take so long when nothing changed?
Both sides read every file that has the same size on the sender and receiver to compute its checksum. On large trees that is a full read of the data on both machines, even if no byte is transferred afterwards.
Is rsync -c the same as rsync -I?
No. -I (--ignore-times) turns off the quick check, so every file is updated (with the delta algorithm, which still reads the data). -c skips files whose contents match, so unchanged files are not touched.