"Last changed" timestamp is ignored?

[Matt McCutchen]

On 6/14/07, Carey O'Shea <carey at internode.on.net> wrote:
> Rsync's "does this file need to be updated" check can conclude "this
> file does not need updating" even though the "last changed" timestamp
> differs. This happens when the size and modify timestamp are equal. Why
> doesn't rsync consider the "last changed" timestamp in the same respect
> as the modify timestamp? Doesn't changed mean, er, changed?
>
> I noticed this when editing some Ogg Vorbis tags with a tag editing
> program (Easytag). The size and modify timestamp remained the same, with
> only the "last changed" timestamp being different. The updates were not
> transferred because rsync saw that the size and modify time were the
> same, and concluded the file did not need updating, despite the "last
> changed" timestamp being different.

User programs cannot set ctimes (ctime = "last changed" time)
arbitrarily, so rsync cannot set a destination file's ctime to match
the source file's ctime; the times will inevitably differ.  If rsync
transferred files that differ in ctime, then it would always transfer
every file, which defeats the whole purpose of a quick check.

In choosing which attributes to use in the quick check criterion, we
run up against a fundamental limitation.  In order for rsync to record
that it has copied the data of the source file to the destination
file, it must also copy those attributes to the destination file.  To
do that, it must be able to set those attributes of the destination
file arbitrarily.  But if rsync can do that, other programs (like
Easytag) can do it too and fool rsync into thinking a file doesn't
need a transfer when it really does.  The only ways to overcome this
limitation and get a perfect quick check are to save additional state
on the sender (compare to git's stat cache) or to use a filesystem
with built-in support for file checksumming, and neither approach is
currently practical for rsync.

Rsync's quick check is good enough for almost all uses because it is
universally accepted practice that a program that modifies a file's
data should not then set the file's mtime back to the original value.
Easytag evidently broke this convention, and rsync was fooled.  I
believe that the fault lies with Easytag, not rsync.

Matt