rsync-2.6.2: NFS clients confused after an rsync

John Van Essen vanes002 at
Wed May 12 02:44:04 GMT 2004

On Tue, 11 May 2004, Wayne Davison <wayned at> wrote:
> On Tue, May 11, 2004 at 01:48:33PM -0400, Brian Childs wrote:
>> Yes.  Without the -b, it doesn't happen.
> OK, I think I know why now:  without -b the old inode goes away, and
> thus NFS gets some indication that a change has occurred in the data
> it has cached.

I disagree.  I think Brian had it right:

On Thu, 6 May 2004, Brian Childs <brian at> wrote:
> What I think is happening:
> --------------------------
> * testfile is updated in place, so the mtime of testpath
>   isn't udpated.
> * The nfs client is caching the mtime of "testpath"
> * The seconds rsync modifies the contents of testpath, but
>   when finished, it resets the mtime on "testpath"
> * The client believes it's cache is valid, so I doesn't refresh,
>   and therefore it misses the update

Rsync is doing a Bad Thing when it creates in a directory a new
file (the backup file) that is not part of the source content,
and then *changes the mtime* of the directory back to its source
content value(!).

It should be left in its modified non-rsync'ed state since the
target directory content no longer matches the source content.

Anyone who uses a --backup option is subverting the 'exact'
directory replication that rsync normally does, so I think that
never preserving directory modtimes is appropriate for --backup.

I think Brian's very simple patch (refined version posted 5/11)
using an extra set_modtime() arg and testing for make_backup is
the right fix.  That fix could be refined even further by also
checking for any specified backup-dir.  If one was given, then
it will be OK to always restore mod times in the original target
location since no backup files are being created there.
        John Van Essen  Univ of MN Alumnus  <vanes002 at>

More information about the rsync mailing list