NOTE: Sadly, it turns out that this has nothing to do with file timestamps.
Per the info given in that other post, I tried --modify-window=30
and even --modify-window=300
, but that did not change the incorrect behavior that I'm reporting. And this has nothing to do with timezone differences, either, because rsync
correctly identifies most files that are identical between source and destination.
I'm using rsync
to back up a large amount of data from the file system on a linux machine (Ubuntu 20.04 using the ext4
filesystem) to a file system on a mac (Big Sur 11.7 using the APFS Data Volume
filesystem). Because of differences in the OS, some identical files are shown to be different when queried by rsync
on linux and on the mac. This discrepancy causes quite a few files which are identical between the source and destination to always be transferred during each rsync
run.
... but not all files. Most identical files correctly do not get transferred. But out of the few thousand files on my linux machine, a few hundred files that are identical between source and destination are always consistently treated as non-identical during rsync
.
This is the command I'm running ...
rsync -avz -i -e 'ssh -p 6000' --ignore-errors "--exclude-from=excludes" --delete-excluded --delete-during / [email protected]:/var/backup
I have also tried it with other options, such as --no-o
, --no-g
, and --no-D
, but I still get the same results.
And these are the contents of the excludes
file ...
excludes
swapfile
mnt
media
tmp
opt/tmp
var/tmp
var/log
run/user
proc
dev
sys
**/lost+found*/
**/*Trash*/
**/*trash*/
**/.cache/mozilla/**
**/.cache/waterfox/**
**/brave/resources/**
**/usr/src/linux*/**
**/.mbsync/**
**/snap/**
**/snapd/**
**/flatpak/**
*.qcow2
*.iso
Also ...
Per the suggestion that was given to me, I re-installed rsync
on the Mac via homebrew and retried the sync after having added --rsync-path=/usr/local/bin/rsync
to the rsync
command line (that's the location where homebrew installs it). Sadly, using that homebrew version of rsync
did not fix the problem.
And furthermore ...
I tried this both with and without the --checksum
option, and with a few different --block-size
options that go along with --checksum
. I also tried this with and without --sparse
. None of these things fixed the problem, either.
And to repeat some things that I wrote before but which were discussed in comments of mine that other people deleted ...
I can run the rsync
command over and over with absolutely NO changes having taken place either for the source or the destination, and yet, the exact, same subset of files and directories are always and repeatedly shown as being different between source and destination, even though all of them are totally identical in terms of contents, size, and timestamps, and even though all of them are totally unchanging.
And by identical size, I mean that the sizes are precisely equal when measured in bytes.
I strongly suspect that this incorrect rsync
behavior is due to the fact that the source is on a linux ext4
filesystem and the destination is on a MacOS APFS
filesystem. I suspect that there is something about this difference in filesystems which confuses one or more of the file comparison algorithms that rsync
makes use of.
Hmm ... perhaps could it be that the APFS
filesystem confuses "access time" with "modification time"?
ls -ld
, and the sizes and timestamps are shown to be the same both in source and destination. I had to use theFinder
in MacOS to get the more detailed timestamp that I could get vials -ld --full-time
under linux.<f+++++++++ usr/share/terminfo/x/xterm+256color
, Every copied file always is indicated like this example, with the<f+++++++++
prefix.*deleting usr/share/terminfo/x/xterm+256color
. However, nothing in theexcludes
file which I listed above matches this path, nor any of the other several hundred other files which are identical between source and destination and which still get copied, anyway.rsync
might not "see" the source and therefore delete the corresponding destination, but then suddenly begin to "see" the source after all, and then copy it. And again, there is nothing else running on either host whenrsync
runs, and nothing changes the source or destination. And it's always the exact, same subset of files and directories which exhibit this behavior./usr/share/terminfo
are not symlinks, but rather, just normal, regular text files.