rsync-2.6.2: NFS clients confused after an rsync

[Wayne Davison]

On Tue, May 11, 2004 at 09:44:04PM -0500, John Van Essen wrote:
> On Tue, 11 May 2004, Wayne Davison <wayned at samba.org> wrote:
> > 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.

You're missing the subtlety of what I was discussing there: the glitch
does not appear when rsync just replaces a file with a new one, an act
that should have tweaked the directory's modtime on a normal update but
doesn't when rsync does it (remember that rsync does not normally update
files in-place).  The difference between the two is that, when using -b,
the old inode still exists in the directory and remains unchanged (even
though renamed).  When the inode goes away (w/o -b), NFS notices the
directory update, even though the directory's modtime was not changed.

> 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.

The extra-check for a specified backup-dir is certainly something that I
had also thought should be added to that proposed solution.  However,
there have been other problems with the preserving of directory modtimes
(such as some systems not even allowing it), so the question has arisen
before:

Why should we preserve directory times by default?  I'm interested in
what people think about this more general change.

..wayne..