Confused as to why rsync thinks time, owner and group of many files differ
andy at strugglers.net
Thu Feb 3 23:48:48 UTC 2022
On Thu, Feb 03, 2022 at 05:38:41PM -0500, Kevin Korb via rsync wrote:
> Are you using the same source and target each time?
> I ask because the only discrepancy I see is the link count which
> shows that there are 11 more instances of that inode on the source
> than the target. Maybe instances in other snapshots are being
I haven't yet let rsync run all the way through the whole source
filesystem so it probably hasn't yet sent over some of the hardlinks
that it knows about for this file.
There's only ever one rsync going at once, because this is a one-off
thing I am doing by hand.
> The only other thing to mention is that when you abort rsync (with -P or
> --inplace) incomplete files are left. Rsync doesn't fix the owner+group
> until it is done with a directory and it doesn't fix the timestamp until it
> is done with a file. This would be why you shouldn't mix those options with
> --update since the truncated file will be newer than the source file.
- it's thousands of files that are reported as having differing
t/o/g, not just whichever one was being worked on when I hit
ctrl-c. I'm only hitting ctrl-c because rsync sees thousands of
changes that I can't explain.
- they don't have differing t/o/g when you look at them.
- their contents are identical anyway as confirmed by sha256sum and
also as confirmed by the fact that rsync isn't sending the file
- if I use "-I --checksum" to skip mtime checking and force
checksum, rsync doesn't try to sync these files (it does still for
the ones it thinks o/g are different). This partial workaround
isn't very useful anyway as --checksum takes forever. Point is, it
definitely thinks there are changes of mtime, uid and/or gid.
So I am still really confused.
If I remove the --inplace I think the spurious t/o/g detection will
still happen, and also that rsync will create a temp file to rename
over each file, so blowing up the hardlinks that it has already sent
This would be mere curiosity if it did this once and then was happy
that it had set the mtime/uid/gid, but it doesn't, it does it every
time, which is making things really slow.
I am trying to build a newer rsync for use on the sender to see if
that makes any difference but am also running into bizarre problems
there, which is perhaps for another thread. Illegal instruction
somewhere inside libcrypto. The same libcrypto that the packaged
rsync is linked against. Goes away if I use --cc=none, but happens
for md4 or md5. Really not my night!
I am tempted to blow away the btrfs filesystem and just do xfs to
xfs, to rule out weird issues there. It would be a shame though as
I was hoping to use btrfs's compression here.
More information about the rsync