Unintuitive backwards-incompatible behaviour with rsync -a --link-dest --size-only

[Bryan Hoyt | Brush Technology]

I use rsync to backup my system, using a command-line such as the following:
> rsync [src] [dst] -a --link-dest --size-only

In this case, [src] is produced by a command that makes no attempt to
preserve timestamps ("svnadmin hotcopy", in this case). That's why I use
--size-only.

Here's the rub: identical files aren't hard-linked like I expect them to be.
They're full copies. And the reason is that the timestamps are different
(I've tested that in various ways, and am able to produce correctly
hardlinked backups by manually forcing the timestamps to be identical.)

Is this because --size-only doesn't affect the behaviour of --link-dest, but
only the transfer comparison? Should it affect --link-dest in a similar way?

I've worked around this issue by specifying "--no-times" on the rsync
command line. This does what I want, although as far as I can make out, it's
only due to a side-effect that it actually works (I don't really care
whether timestamps are preserved or not, in this case -- they're bogus
anyway).

The other weird thing is that --size-only *used* to work as I expect, with
identical command-line, leaving off the "--no-times" flag. I've had this
backup system in place for a few years, and it's always worked smoothly.
Then when I upgraded from an old version of Redhat to a recent version of
Ubuntu (10.10), the backups suddenly shot up massively in size, for this
reason. I have not changed the rsync command line before or after the Ubuntu
upgrade.

Has rsync's behaviour changed in this respect in the last 2-3 years?

Is this a bug?

 - Bryan

-- 
PS. Check out the Brush newsletter: *Subscribe or read our previous
newsletters* <http://brush.co.nz/newsletters>

Bryan Hoyt, *Web Development Manager*  --  Brush Technology
*Ph:* +64 3 741 1204     *Mobile:* +64 21 238 7955
*Web:* brush.co.nz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20110312/3842f6ce/attachment.html>