meta bug: info on "why" xfer seems no longer available? (3.1.0)

L. A. Walsh rsync at
Sat Aug 9 11:41:25 MDT 2014

I just copied a file system using


At least 1 new directory had been created on the source during the
xfer (took 9+hours -- 7TB), so I wanted to verify I hadn't missed anything.

Using rsync:

>  rsync --version
rsync  version 3.1.0  protocol version 31
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes, prealloc, SLP

did:  rsync -auvnHAX /oDATA/. /DATA/.

got back a rather large list
of 4 directories and 13708 files!...

So wanted to see WHY it wanted to update them, as I thought
the full xfsdump/restore should have resulted in an exact copy.

Tried :

rsync -auvvnHAX /oDATA/. /DATA/.

which manpage said would list "why"...
it didn't.

I got an 84276 line summary, that
Showed all of the files... with
<filename> is uptodate
and <filename> (and nothing else) on lines where it wasn't uptodate.

total: matches=0  hash_hits=0  false_alarms=0 data=0

sent 4,482,129 bytes  received 8,653,370 bytes  1,142,217.30 bytes/sec
total size is 8,329,967,491,093  speedup is 634,156.91 (DRY RUN)

I tried -vvv, but didn't see anything in the 596694 line output
file that told reasons...

Lots of [sender] makefile(xxcxx,*,2)
[sender] pusing local filters..(by dir?)

received 5 names
recv_file_list done
[receiver] receiving flist for dir 14

but still no reasons (I could be missing them in all
all the output, but don't see other types of lines...)

Is there some other option now to determine the reason why a file
was xfered?

More information about the rsync mailing list