Unintuitive backwards-incompatible behaviour with rsync -a --link-dest --size-only
Bryan Hoyt | Brush Technology
bryan at brush.co.nz
Wed Mar 16 18:34:10 MDT 2011
Is anybody able to shed insight on this issue for me?
Thanks in advance!
On Sat, Mar 12, 2011 at 11:30, Bryan Hoyt | Brush Technology <
bryan at brush.co.nz> wrote:
> I use rsync to backup my system, using a command-line such as the
> > 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
> 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
> 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
> 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
> Has rsync's behaviour changed in this respect in the last 2-3 years?
> Is this a bug?
> - Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rsync