rsync - Jun 2007 - "Last changed" timestamp is ignored?

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.

I see no reason to have to make my transfers take multitudes longer with 
--checksum or --ignore-times when simply checking the "last changed" 
timestamp in the same manner as the modify timestamp would be trivial as 
far as I know.

Perhaps there is already support for this and I'm just not aware of the 
option? If so, then why isn't it the default?

I'm using rsync 2.6.9.

On 6/14/07, Carey O'Shea <carey@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

On Fri, Jun 15, 2007 at 03:44:12AM +0930, Carey O'Shea
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?
The modified timestamp is the last-changed timestamp.  If you're
referring to the ctime, that is the time the inode was last changed,
which is something different (and it can stay the same when a file's
data is changed, and can change when a file has unchanged data).  The
only other posix timestamp is last accessed time.
> I noticed this when editing some Ogg Vorbis tags with a tag editing 
> program (Easytag).
That's a shortcoming with easytag, then.  If it modifies a file and sets
the modified timestamp back to its pre-changed value, it is masking the
change.

..wayne..