cwrsync and link-dest option
matt at mattmccutchen.net
Tue Mar 16 19:48:59 MDT 2010
On Mon, 2010-03-15 at 13:35 +0100, Stefan Agner wrote:
> In a small environment I have to backup two servers, an Ubuntu 9.10
> and a Windows Server 2008 machine. My Backuphost is a Ubuntu 9.10
> machine as well. I installed rsync on both Ubuntu hosts from
> repository (3.0.6) and cwrsync from http://www.itefix.no/i2/node/10650
> (3.0.7). Then I wrote some Bash-Scripts which executes rsync every
> week like that:
> rsync -v -a 192.168.x.y::data $BACKUPDIR/weekly.0
> And every day like that:
> rsync -v -a --link-dest=$BACKUPDIR/weekly.0 192.168.x.y::data
> In the backups of the Ubuntu host, I can see that the Inode number of
> the same file in weekly.0 and daily.0 is the same (ls -lai shows the
> files with a blue background as well). On Windows this doesn't work.
> But the file are definitly unchanged (verified with md5sum). As far as
> I could see all file attributes are the same as well (size, date,
> rights)... Anyway, I think that rsync detects something different at
> the files, which is not obvious to me. Does link-dest with cwrsync
> works for you? Is there any problem known with link-dest and cwrsync?
> Which attributes are checked by rsync to decide if it should copy the
> file again or link it?
The attributes checked for --link-dest are those for the quick check (by
default, size and mtime) plus any you have asked rsync to preserve. In
this case, you passed -a, so rsync will also check the permissions and
maybe also the user and group owners depending on whether the receiver
runs as root. The permissions and user/group ownership exposed via the
cygwin interface on Windows are not always meaningful; you could avoid
preserving them by passing simply -rt instead of -a.
The recommended way to find out which attribute is disqualifying a hard
link is to pass -i (--itemize-changes). See the man page for what the
More information about the rsync