[Bug 11521] rsync does not use high-resolution timestamps to determine file differences

[f-rsync at media.mit.edu]

[Included text copied from the commit.]

    > Date: Sun, 24 Jan 2016 19:52:49 +0000
    > From: samba-bugs at samba.org

    > Auto-Submitted: auto-generated

    > https://bugzilla.samba.org/show_bug.cgi?id=11521

    > Wayne Davison <wayned at samba.org> changed:

    >            What    |Removed                     |Added
    > ----------------------------------------------------------------------------
    >              Status|NEW                         |RESOLVED
    >          Resolution|---                         |FIXED

    > --- Comment #3 from Wayne Davison <wayned at samba.org> ---
    > The latest git version has an option that lets you choose to include
    > nanoseconds in comparisons if you want them. Having it on by default would
    > likely cause far too many headaches for various backup solutions that use an
    > older filesystem (e.g. ext3) that doesn't support nanoseconds.

Thanks for the patch!

Just FYI, this comment is true but incomplete---the scenario I was
describing was straight ext4-to-ext4 copies and/or backups.  The
timestamp problem I currently see with those is because rsync was
throwing away the nanosecond information until this patch, even though
both ends supported it.

Anyone who's used dirvish, or presumably similar tools such as
rsnapshot, from and to ext4 or other ns-supporting filesystems, will
be bitten by the problem of non-ns vs ns timestamps bloating backups
and breaking hardlinks, either when they manually use --modify-window=-1,
or when this becomes the default.

I'd still love to see either some in-rsync workaround that can be left
in place*, or (second best) some clever by-hand one-time workaround
that uses rsync just once to update all those timestamps while not
breaking the hardlinks (presumably -not- using --link-dest for those),
or (third best) some not-rsync-at-all solution that basically does
a giant ls at the source and a giant touch at the destination.  Yes,
I know that none of those can fix up backed-up files that are no
longer in the same place in the source; those at least won't bloat/
unhardlink later backups.

This solution is likely going to have to be reinvented repeatedly by
people running backups, so working out the right way to do it and then
putting it somewhere other rsync users will find it is likely a useful
exercise.  Before I solve it by hand for myself, it'd be useful to
know if it's likely rsync will come up with some way to solve it for
me.

* E.g., (a) "If modify-window is -1, and --link-dest is in use, and
everything else about the file or directory matches -except- the
timestamp, then update the timestamp," and (b) "Provide a switch to
turn off this heuristic after I'm sure my backups are okay."  (The
intent of (b) is to catch later slight changes of timestamp but
actually record them as -separate files-, which is important so
older snapshots don't magically change out from under you if something
updates a timestamp by a fraction of a second without otherwise
changing anything, which does happen and can occasionally be -very-
important to know about when tracking down issues.)