cwrsync and link-dest option

[Matt McCutchen]

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:
> BACKUPDIR=/var/backup
> 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  
> $BACKUPDIR/daily.0
> 
> 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
output means.

-- 
Matt