2

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:

f..t...... <file>

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)

  • Unix doesn't have a system call to set the change time of a file. AFAIK, it's always set automatically to the current time any time you perform an operation that modifies the inode. I can't explain how the change time of the destination file is being set to something in the past. – Barmar Jan 24 '17 at 20:34
  • Nor can I explain what touch is doing. – Barmar Jan 24 '17 at 20:34
  • The rsync documentation just says that --times copies the modification time, it doesn't say anything about the inode change time. – Barmar Jan 24 '17 at 20:35
  • I just checked the source code of the touch command, it never does anything to get the reference file's change time, so it can't copy it to the target file. There's no way your touch command could have done what you say. – Barmar Jan 24 '17 at 20:42
  • @Barmar Indeed, the change time cannot be set, even by root (except indirectly by changing the system clock or bypassing the filesystem driver), except by various operations that set it to the current time. There may be something peculiar with CIFS that causes the reported ctime not to be what unix would consider the ctime, but I don't know how that could affect rsync. – Gilles Jan 25 '17 at 0:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.