rsync-2.6.2: NFS clients confused after an rsync

[John Van Essen]

On Tue, 11 May 2004, Wayne Davison <wayned at samba.org> 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 rentec.com> 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 umn.edu>