-c Option

Eric Ziegast ziegast at vix.com
Thu May 30 11:29:01 EST 2002


> Quick question....can anyone explain to me when the data in a file
> might change without changing the mtime, ctime or size?  I'm not
> sure I've ever come across that before.  An example might help me
> determine if I can safely remove -c.

It's possible on Unix systems, but not practical.

An example script:

  #!/bin/sh
  # Run on a BSD Unix system, your touch(1) arguments may vary
  echo "foo" > File
  touch -t 200205300800 File
  ls -l File
  echo "foo" > File
  ls -l File
  touch -t 200205300800 File
  ls -l File

Output:

  -rw-r--r--  1 ziegast  ziegast  4 May 30 08:00 File
  -rw-r--r--  1 ziegast  ziegast  4 May 30 11:19 File
  -rw-r--r--  1 ziegast  ziegast  4 May 30 08:00 File


Here's one example where I might use -c:

  Hackers are not known for being practical.  They like to cover their
  tracks as best they can by setting the owner, group, permissions, size,
  mtime, and ctime of their fake programs to be the same as the original
  programs.  If you're distributing system software using rsync or rdist,
  you may want to force checksum comparisons just to be sure.

  One might also use rsync with "-n -c" to help compare a "gold copy"
  of OS files with an active system.  Then again, tripwire was designed
  to do this better.


Another example is when some network-based filesystems delay updating
their metadata even though the content has changed.  I remember once
using a client machine to update a file on a busy NFS server.  It took
several seconds for the change to be seen by another client machine.
If I were using rsync on the second client machine, its view of the
file might be inconsistent.  Then again, best practices would dictate
my wanting to run rsync on the NFS server and not on the clients that
might be inconsistent with the server (to keep network traffic down
and reduce overhead).

--
Eric Ziegast




More information about the rsync mailing list