Why Does Rsync Recopy Files When Size and the Displayed Date Match?

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Rsync can recopy files whose visible size and date match when their raw modification times, comparison rules, or transfer options still differ.

File browsers often hide subsecond timestamps and show only a rounded local date, while Rsync compares the metadata exposed by each endpoint and can also be instructed to ignore time matches, compare checksums, or update metadata. A job may therefore report the same human-readable size and date yet still select the file because nanoseconds differ, one filesystem rounds time, an SMB client rewrites the timestamp, or the command explicitly bypasses the normal quick check.

Confirm That Rsync Is Selecting the File for Data Transfer

Run the job as a dry run with itemized changes and save the exact command, source path, destination path, Rsync versions, and one representative filename.

The official Rsync manual explains that the default quick check compares file size and modification time, while itemized output identifies which attributes caused an update.

If the itemized code shows only permissions, owner, group, ACL, or extended-attribute changes, the file may be revisited without retransmitting its full payload.

Compare Raw Modification Times Instead of the Displayed Date

Read the source and destination modification times with nanosecond precision and compare their numeric epoch values from the systems that run the sender and receiver.

The Linux stat structure supports nanosecond timestamps, so two files displayed as the same second can still have different values.

A browser showing only minutes or seconds cannot prove the underlying modification times match. Record raw values before touching the files again.

Check Timestamp Precision and the Modify Window

Identify every filesystem in the path, including FAT, exFAT, NTFS, SMB, NFS, archive extraction, and removable staging volumes.

The Debian Rsync manual documents modify-window behavior, including tolerance for filesystems that cannot store identical timestamp precision.

Use a nonzero window only after measuring the difference. A window that is too broad can hide a genuinely changed same-size file.

Audit Flags That Override the Normal Quick Check

Inspect the complete scheduled command and any wrapper script, NAS interface, environment variable, include file, or preset that adds options.

The Ubuntu Rsync reference states that ignore-times forces updates, checksum mode replaces the time test, and size-only ignores modification time.

Remove only the proven flag. Checksum mode can add heavy reads even when little data crosses the network.

Check Whether SMB or Windows Rewrites the Destination Time

Hash and timestamp the destination immediately after transfer, after closing the SMB session, and after reopening it from another client.

Microsoft documents that applications can set and retrieve file timestamps, while filesystems and applications can update individual fields on different schedules.

If the destination time changes only after an indexer, media app, cloud client, or SMB workflow touches it, correct that writer rather than Rsync.

Separate Modification Time From Other Metadata

Compare modification time, status-change time, permissions, ownership, ACLs, extended attributes, hard links, and symbolic links.

NetBSDโ€™s stat utility exposes raw file status fields, helping distinguish content modification time from other metadata changes.

Archive, ACL, xattr, owner, or group options can trigger metadata work. Read the itemized code instead of treating every listed path as a full payload transfer.

Run a One-File Test and Fix the Smallest Proven Difference

Copy one closed test file, preserve the intended metadata, rerun the identical command, and compare itemized output, transferred bytes, and raw timestamps.

The ZimaSpace article on unexpectedly large incremental backups covers wider backup-chain causes; this article isolates Rsyncโ€™s file-selection rules.

The issue is resolved when a no-change rerun skips the test file or performs only the metadata update you intentionally configured.

Frequently Asked Questions

Why do the dates look identical in the file browser?

The browser may round to seconds or minutes and display local time, while Rsync receives a more precise modification timestamp.

Will checksum mode stop unnecessary copies?

It can avoid transfer when contents match despite different times, but it must read and hash same-size files on both sides.

Can time zones cause repeated Rsync transfers?

A timezone display alone should not change numeric timestamps, but applications or filesystems that convert or round them can.

Support & Tips

More to Read

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.