I have been trying to figure out this rsync behavior, where it still lists directories with different timestamps and the same sizes despite providing a --size-only flag.

# lists some directory without listing any changed files
> rsync -av [path 1] [path 2] --dry-run --size-only
> building file list ... done
> folder1/folder1a/
> folder1/folder1b/

# checks reasons with -i
# ...
> .d..t....folder1/folder1a/
> .d..t....folder1/folder1b/

As you can see, --itemize-change shows that the only difference between the source and destination folders is the timestamp. But it is still listed in my regular rsync run despite providing --size-only. Is there a way to fix this? It seems like it still modifies the destination folder if I were to run it, which causes a folder reupload in my cloud backup services. Thanks!

EDIT: rsync version is 2.6.9. Source is a folder with subfolders inside it, and inside which are random files. Destination is my OneDrive folder. It should be identical to the source, but after running rsync to transfer the folders, it seems like OneDrive touches the folders and making future rsync see them as different (and nothing else manual is happening when rsync is being run). I don't mind that, but I just don't want rsync to update them further when run in the future. Hence I add the --size-only flag to ignore timestamp differences. What I am trying to understand is why these dir's are still being listed, even though the change reported by --itemize-change is only timestamp difference (.d..t....)? I just don't want them to be re-transferred every time I run rsync simply because they have different timestamps.

EDIT 2: At first I uploaded them onto OneDrive (not w/ rsync), then ran rsync with --size-only on the folder later. As a result the mod time of the destination files are never changed. While --size-only skips over the file themselves, the folder is still seen as "different". So I think that even though the only difference on the folders itself is timestamp (.d..t....), it still updates the folder as the files inside are perceived to be different (even with --size-only). Once I rsync'd everything without --size-only one time, the problem disappeared since the mod time of files inside have changed.

But this behavior is undesirable, since the folder and the files themselves are identical aside from timestamps, so --size-only should ignore the folder altogether. I am only intending to use rsync to fill missed files after uploading onto OneDrive (web), and not rsync them from the get-go (as sometimes syncing changes from local drive with OneDrive is very very slow compared to uploading). Is there a way around this? How can I stop rsync from updating directories whose contents are identical size-wise?

  • What version of rsync?
    – mmmmmm
    Aug 9, 2022 at 20:37
  • If you want a clear answer, please clarify your question. What is the source? What is the destination? Is anything happening to your source & destination between runs of rsync?
    – Seamus
    Aug 9, 2022 at 22:14
  • @Seamus added edit to clarify the problem
    – Donald Zhu
    Aug 9, 2022 at 23:12
  • 1
    That's much better thanks. Don't have time for an answer now, but will get back to you. In the meantime, you may be interested in this recipe I posted on GitHub recently. In particular, there is a procedure with a couple of scripts to compare your source to your destination.
    – Seamus
    Aug 10, 2022 at 10:03
  • @Seamus Thanks for the info. I added some edit to the question as I narrowed down on what my problem is.
    – Donald Zhu
    Aug 10, 2022 at 20:34

1 Answer 1


The rsync command you're using: rsync -av ...

If you refer to man rsync, note the following:

-a, --archive archive mode; same as -rlptgoD (no -H)

In other words: -a implies the options: -rlptgoD

Note that option -t is defined in man rsync as follows:

-t, --times preserve time

Now, for the --size-only option, man rsync tells us:

Normally rsync will not transfer any files that are already the same size and have the same modification time-stamp. With the --size-only option, files will not be transferred if they have the same size, regard-less of timestamp. This is useful when starting to use rsync after using another mirroring system which may not preserve timestamps exactly.

I have not had time to verify this (I'll let you do that if you don't mind), but what I think this means is that while no file is being transferred (it's a folder) due to --size-only, the -t option (implied with -a) is causing the folder's time stamp (modification time) is being updated by rsync. You can verify that by changing the rsync command you're using to:

rsync -rlpgoDv --dry-run --size-only [path 1] [path 2] --dry-run --size-only

Note there are two (2) changes here; one to eliminate the (implied) -t option, the other to place all options prior to the Source & Destination locations to correspond with the command syntax under SYNOPSIS in man rsync. Also, I seem to vaguely recall reading somewhere that misplacing options in rsync created issues.

To reiterate some of the comments:

  • See the table at the bottom of the GitHub recipe to help decode the -i output.

  • The recipe also contains a procedure & script you may consider using to verify you are getting exactly what you want; the get-stats.sh script - or simply using the stat command selectively - will allow you to verify the time-stamps.

  • If you're using ver 2.6.9 of rsync, you should probably invest some time to upgrade to a current version. I recommend MacPorts for this. If you have any detailed questions on how to go about that, those are probably best handled under a new question.

  • you are right, removing the implied -t changed everything
    – Donald Zhu
    Aug 10, 2022 at 23:47
  • Note also that -v implies a bunch of progress reporting options. Check man rsync and look for the --info flag to replace -v with a narrower list of options for reporting.
    – NeilG
    Apr 22, 2023 at 5:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .