Link-dest breaks on uid/gid mismatches

[Chris Davies]

I want to use rsync to backup a couple of Windows systems to a central 
point. To this end I installed the "DeltaCopy" implementation of an 
rsync server on the Windows boxes. On the central server I have rsync 
3.0.7 running on a Debian GNU/Linux distribution. (I also have a similar 
configuration but with a QNAP - a NAS with bells on - as the central 
backup point. Since both exhibit the same behaviour I'm going to stay 
with the more common scenario.) I also have rsnapshot in the mix but to 
keep things simple I'm going to ignore that for now.

A cut-down example rsync command could be something like this,

rsync -avxH --delete --numeric-ids --relative --delete-excluded 
--modify-window=1 --password-file=/etc/rsnapshot.secret 
--link-dest=/backup/last/ rsync://rsync@windows/DocumentsAndSettings 
/backup/this/

If this call contacts a Linux based system, the hard links between files 
in /backup/last/... and their unchanged counterparts in /backup/this/ 
are created by the --link-dest option as expected. If this contacts a 
Windows based system running DeltaCopy they are not linked. Ever.

I believe I have narrowed this down to a mismatch between the UID/GID 
values on the Windows side and the Linux side. What appears to be 
happening is that the Windows system is providing UID/GID values in a 
range that cannot be handled by the Linux system, and so it is 
truncating/converting them to 0/0. Then, when the next rsync runs, the 
UID/GID values provided by the Windows system do not match 0/0 and so 
copy is made of the file. (This is fast as it's built from the 
--link-dest item, but nevertheless it's a copy.) The resulting copy 
cannot have its UID/GID values applied correctly as they are out of the 
valid range on the Linux side, and so they are again truncated/converted 
to 0/0. And so on.

The work-around is to apply --no-owner and --no-group to the rsync 
command line, at which point the files are owned by the caller of the 
rsync command on the central server and --link-dest can work as 
expected. However, I believe a better solution would, if possible, be to 
force the UID/GID values into a valid range before comparing them to an 
existing file referenced via --link-dest.

Additional comments -
1. I haven't tried an alternative Windows client (e.g. cygwin/rsync) as 
this is outside the scope of what I can change on these systems. 
Therefore I cannot be sure whether this is a client or server issue, 
i.e. I cannot confirm that this fault report belongs to rsync rather 
than to DeltaCopy
2. I did get a UID/GID range error at one point but I can neither 
reproduce it nor remember it sufficiently accurately to want to cite it here

Any other thoughts, please? Should I report this as a bug?

Cheers,
Chris