Skip to content
Go back

Rsync - a powerful tool to sync the disk

Updated:
Edit page

debian13

I’ve been deep in the Linux world for years - everything in my IT life runs on it because it’s open source, secure, and totally transparent. I’m all about the command line: it’s lightweight, no extra fluff, just clear commands showing exactly what’s happening behind the scenes. Rsync fits perfectly in this philosophy. It works flawlessly across all Unix-like systems I use - Manjaro, Debian, Fedora, even macOS.

My data is everything: work code, documents, personal photos. I keep backups everywhere - three spots minimum. There’s my master Linux machine (currently Debian 13), a Mac, and two encrypted external drives with VeraCrypt. Syncing all that used to be a headache until I discovered rsync. It’s straightforward, reliable, and handles syncing between these devices effortlessly, making life way easier and keeping my digital world safe and in sync without complicated tools.

That behavior, while it seems inconsistent, is normal for rsync and is directly related to how the --archive, --delete, and -P flags interact.

In short, rsync is silent when the source and destination are identical. It prints the file tree when it needs to transfer data, update file attributes, or delete files. The --delete flag can sometimes force a deeper comparison that results in output even if no files are ultimately changed.

Why It’s Usually Silent 🤫

When you run rsync with your flags, its goal is to make the destination an exact mirror of the source. If it checks the source and destination and finds no differences in file content, size, modification times, permissions, or ownership, then its job is done. There is nothing to transfer, update, or delete.

The -P flag (which combines --progress and --partial) only shows progress bars for files that are actually being transferred. If no files are being transferred, it will show nothing. This is the most common reason for a silent command line: the directories are already perfectly in sync.

Why It Sometimes Prints Everything 📜

There are a few key reasons why rsync would print the file list even when you believe no files have changed.

1. The --delete Flag’s Verification Process

The --delete flag tells rsync to remove any files at the destination that no longer exist at the source. To do this safely, rsync must perform a full scan of both the source and destination directories to build a complete file list. This process itself can generate the “receiving file list…” message and may appear as if it’s processing everything, even if no deletions ultimately occur.

2. Metadata Mismatches (The Most Common Culprit)

The --archive (-a) flag is a powerful option that syncs much more than just file content. It’s a shortcut for -rlptgoD, which preserves:

If there’s even a tiny difference in these metadata attributes between the source and destination files, rsync will update the file at the destination to make it match. This update will cause the filename to be printed, making you think the file was re-transferred, even though only the metadata was changed. This often happens if you’ve run a command like chmod or chown on one side but not the other, or if the two systems have different default file creation permissions.

3. Clock Skew

A common metadata issue is “clock skew,” where the system clocks on the source and destination machines are not synchronized. If the destination file’s timestamp is in the future relative to the source, rsync can get confused. While it has logic to handle this, severe differences can trigger unnecessary updates.

How to Diagnose the Behavior

To see exactly why rsync is taking action, you can add flags to make its output more verbose.

Example Diagnostic Command

Combine these flags with your existing command to get a detailed report without changing any files.

rsync --archive --delete -P --dry-run --itemize-changes [SOURCE] [DESTINATION]

The output from --itemize-changes will look something like this:

.f..t...... my-document.txt
.d..t...... my-directory/
>f.st...... new-file.txt
*deleting   obsolete-file.txt

Here, the t indicates a timestamp difference was found and would be corrected. By checking the output, you can pinpoint exactly what kind of change is triggering the full printout.


Edit page
Share this post on:

Previous Post
GPG/ GnuPG Practice
Next Post
Release My Book about LangChain AI Projects