To support another group on a different continent, I run an rsync from my Fedora 21 box to a cifs share. The contents of the share were originally copied to a hard disk while some of the groups members were in town, visiting.
The rsync is this:
rsync --no-owner \ --no-group \ --verbose \ --recursive \ --links \ --itemize-changes \ --times \ --omit-dir-times \ <source>/ <destination>
Since then the rsync starts fine but always discovers many files that are re-transferred because the time is out of date. Specifically:
I accidentally discovered that, while I have specified --times, it only updates the modify type, not the change time. The local file looks like this using 'stat':
File: <source file> Size: 214 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769d Inode: 15211788 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 537/ build) Gid: ( 501/ toddb) Access: 2017-01-23 07:08:40.724417237 -0800 Modify: 2010-08-20 21:57:32.000000000 -0700 Change: 2017-01-13 07:17:19.745921010 -0800
And after an rsync run the destination file looks like this:
File: <dest file> Size: 214 Blocks: 16 IO Block: 16384 regular file Device: 3ah/58d Inode: 288918155034656 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 531/ toddb) Gid: ( 501/ toddb) Access: 2017-01-23 07:08:40.000000000 -0800 Modify: 2010-08-20 21:57:32.000000000 -0700 Change: 2010-08-20 21:57:32.000000000 -0700
Note that the destination has equal times for modify and change. This seems correct, but if I run rsync again, the same file gets copied. So on a whim I used this...
touch -r <source> <destination>
... to update all the files reported by rsync as being updated. Now when I do the run, two things are notable. (a) the stat results appear to be the same and (b) rsync no longer retransfers the file.
So what could 'touch' be touching that rsync does not? (and should)