meta bug: info on "why" xfer seems no longer available? (3.1.0)
L. A. Walsh
rsync at tlinx.org
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.
> 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.
rsync -auvvnHAX /oDATA/. /DATA/.
which manpage said would list "why"...
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
[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
More information about the rsync